Im Portage-Tree scheint der kernel schon drin zu sein: development-sources 2.6.0_beta1 Ich hab mir mal die neuen Features mit make menuconfig angeschaut - Wow, wenn das wirklich alles funktioniert wäre der angedachte Sprung auf 3.0 angebracht.
>Ich hab mir mal die neuen Features mit make menuconfig angeschaut - Wow, wenn das > wirklich alles funktioniert wäre der angedachte Sprung auf 3.0 angebracht.
Ich finde, der Sprung ist nicht so groß. Vieles aus 2.6 ist schon lange in den kerneln der Distributoren enthalten, z.B. O1 sheduler, Alsa, ACPI, cpufreq, lm_sensors, ...
Das meiste anderes neue aus 2.6 ist eher unter der Oberfläche und für Anwender wenig sichtbar.
Allerdings nicht im Vanilla Kernel. Wer genau wissen möchte wie der aktuelle Status ist und welche Neuerungen überhaupt reinkommen kann sich diese Seite auf Kernelnewbies anschauen. Liest sich sehr gut, wichtig finde ich auch AGP 3.0 (8x).
Na Schorsch, nicht gleich übertreiben. Der Sprung vom Original 2.4 zum 2.6 ist schon enorm, wenn die einzelnen Distributoren 2.6er Features in den 2.4er reinpatchen, dann sind das trotzdem keine 2.4er Features. Der 3.0er Vorschlag kam übrigens von Linus selber, weil es eben ein großer Schritt war - was daraus wird, wird sich zeigen. Eine Versionshysterie steht aber wohl nicht an.
Nach diversen Postings und diesem Linus-Interview ist es bereits beschlossene Sache, daß Morton schon während der Betaphase allmählich zum Maintainer wird. So wird Linus dann frei, um Kernel 2.7 zu beginnen.
wenn ich z.B. eine Datei auf mein Floppy kopiere bleibt der Kopierdialog so lange geöffnet bis die Datei fertig kopiert ist. Danach nehme ich die Diskette einfach aus dem Laufwerk und fertig.
alles andere ist für DAU's einfach zu kompliziert. Habe auch keine Lust mehr immer und immer wieder auf sowas beim Support für Linux Desktopsysteme hinzuweisen.
Bei mir (RH9.0) dauert es teilweise Minuten bis Dateien, die auf die Floppy kopiert wurden, auch wirklich auf die Diskette geschrieben werden. Spätesten wenn ich die Diskette unmounte wird erst angefangen zu schreiben. Ziemlich nervig. Sehr witzig (...) ist auch das eine Diskette, auch die ich beim letzten mal noch Dateien geschrieben hatte jetzt als schreibgeschützt hingestellt wird. Nach dem nächsten booten gehts dann wieder. Disketten mit Linux ist einfach zum k*****, sorry.
Dann setze in die /etc/fstab für /dev/fd0 als Mountoption sync. Ich arbeite ohnehin lieber mit den mtools an der Konsole. Die schreiben ebenfalls sofort.
Zu supermount: Solange supermount aktiv war, konnte ich UT2003 nicht installieren. Nachdem ich supermount rausgeschmissen und manuell gemountet hatte, funktionierte die Installation.
Ich weiß nicht, was ihr für Probleme habt. Man kann das CD-ROM-Laufwerk doch einfach über das Kontextmenü der CD auf dem Desktop aushängen.
Die mtools sind ja wohl nur was für "shellies". Wozu dann eine grafische GUI mit einem Disketten-Symbol ? Nee, was mich nervt ist, das das ganze wie nicht/kaum getestet aussieht. Das soll doch u.a. für den "normalen-User" sein. Das Disketten-Laufwerk ist für mich jedenfalls nur noch bedingt benutzbar, jedenfalls unzuverlässig.
Man kann das CD-ROM-Laufwerk doch einfach über das Kontextmenü der CD auf dem Desktop aushängen. Aber nur solange nicht irgendein Programm/Shell noch irgendwie am CD rumnippelt. Finde ich eh heiss, das mir ein Computer vorschreibt, das ich die CD nicht rausnehmen darf. Ich soll mich dann auf die Suche machen nach einem Programm was vielleicht vor 20 Minuten mal auf die CD zugegriffen hat...
Aber nur solange nicht irgendein Programm/Shell noch irgendwie am CD rumnippelt. Das gilt aber auch für ein umount auf der Konsole. ;-) Finde ich eh heiss, das mir ein Computer vorschreibt, das ich die CD nicht rausnehmen darf. Er bewahrt dich halt davor, ein Medium zu entfernen, auf welches noch zugegriffen wird. So kannst du auch nicht aus Versehen einen Rohling zerschießen, weil du nicht daran gedacht hast, dass im Hintergrund noch gebrannt wird. Nur schade, dass sich Disketten nicht locken lassen. Denn wenn man dort async schreibt, und die Diskette zu früh raus nimmt, wars das. Deswegen hat der Mac auch keinen Auswurfknopf am Diskettenlaufwerk gehabt.
Ich soll mich dann auf die Suche machen nach einem Programm was vielleicht vor 20 Minuten mal auf die CD zugegriffen hat... Nicht vor 20 Minuten. Irgendetwas greift im Moment auf die CD zu. Und sei es nur eine Shell in dem jeweiligen Verzeichnis.
"Er bewahrt dich halt davor, ein Medium zu entfernen, auf welches noch zugegriffen wird. So kannst du auch nicht aus Versehen einen Rohling zerschießen, weil du nicht daran gedacht hast, dass im Hintergrund noch gebrannt wird."
Lese und Schreibzugriff sind doch 2 unterschiedliche paar Schuhe. Die Logik dahinter sollte schon intelligent genug sein.
Supermount-NG Soll sehr gut laufen. Falls jemand Mandrake laufen hat : Im Club und AFAIK im mm Kernel ist es drinne.
> Lese und Schreibzugriff sind doch 2 unterschiedliche paar Schuhe. Die Logik dahinter sollte schon intelligent genug sein.
Auch ein Programm, das nur lesend auf eine CD zugreift kann abstürzen, wenn Du die CD entfernst bzw. kommt in einen inkonsistenten Zustand. Linux ist halt ein Multi-User OS. Du kannst Dir eigentlich nicht sicher sein, daß niemand anderes im Netz auf die Ressourcen zugreift. OK, bei Dir zu hause vielleicht, aber in einem Firmennetzwerk sieht das halt anders aus. Da liegt in einem Rechner die Telefonauskunft-CD und alle dürfen drauf zugreifen. Blöd ist, wenn die jemand entfernt und Du gerade darauf liest.
schlechtes Beispiel. Für einen CD Server würde ich
a) das Supermount ausschalten (supermount -i disable && remount /mnt/cdrom) b) ein Image der CD ziehen da sonst das cdrom nicht lange lebt und der Zugriff von der Platte schneller ist ;)
Wir reden hier von Linux als Desktop OS und nicht als Server. Und für ein Desktop OS ist supermount schon sehr wünschenswert. Und da sich Supermount schnell abschalten und anschalten lässt (ergo optional ist) greift dein Beispiel nicht wirklich.
Ihr beide redet aneinander vorbei. Du erklärst, wo du supermount nutzen würdest und wo nicht, wobei man statt supermount auch genausogut automount nehmen kann. nixname erklärt aber den Grund, dass ein gemountetes Laufwerk gelockt wird. Auch bei supermount kannst du nicht mitten im Lesevorgang die CD herausholen, was bei Windows aber problemlos möglich ist.
Also ich habe beide ausprobiert. Supermount ist ein Kernel-Patch, sobald der Kernel die Option unterstützt, ist das Teil einsatzbereit und ich kann Volumes mounten. Den Automounter habe ich nicht geschafft zum Laufen zu bringen. Soweit ich weiss braucht das auch noch einen userspace-daemon der das koordiniert. Jedenfalls habe ich mit Supermount noch nie Probleme gehabt und mit automaout hat es nie geklappt. Vielleicht fehlt mir auch nur die richtige Doku dazu. Alles was ich bisher gefunden habe erklärt das ganz komisch, da muss ich jeden Mountpoint mehrfach anlegen und das automount-Volume liegt dann imemr auf /mnt/auto/... im Gegensatz zu supermount wo ich jedes Gerät auf jeden Mountpoint mounten kann.
Das einzige was an Supermount nicht passt ist der Samba-Support, das geht noch nicht.
Jetzt lästere mal nicht über den automount-Daemon, nur weil du dir die dazu notwenige Dokumentation nicht durchgelesen und/oder verstanden hast. Natürlich muss bei Automount im Gegensatz zu Supermount ein Userspace Daemon laufen. Und dass dieser Daemon eine Konfigurationsdatei braucht dürfte auch jedem klar sein. Schliesslich muss der Daemon wissen, welche Devices er wohin mounten kann/soll. Wo wir auch gleich beim nächsten Thema wären: den Mountpoints. Die Mountpoints des Automounters liegen mitnichten fest auf /mnt/auto/* (obwohl sie dort IMHO auch sauber hingehören) sondern du kannst in der Automount-Konfiguration natürlich selbst bestimmen, wohin deine Devices gemountet werden sollen.
Das einzige was zu beachten ist: In /etc/fstab steht der ganz normale Mount-Eintrag. Für jeden Eintrag, der in /etc/fstab vorhanden ist und der über den Automount-Daemon gemountet werden soll, muss zusätzlich ein Eintrag in der Automount-Konfiguratgionsdatei erzeugt werden. Das ist aber auch das einzige, was man als Administrator anlegen muss. Wenn du z.B. Webmin verwendest, kannst du den Automounter wahrscheinlich auch über eine Webschnittstelle administrieren ohne in die Tiefen der Automounter-Syntax abzusteigen.
> Jetzt lästere mal nicht über den automount-Daemon, nur weil du dir die dazu > notwenige Dokumentation nicht durchgelesen und/oder verstanden hast.
Ich lästere nicht, ich schildere meine Erfahrungen. Gelesen habe ich die Doku schon. Vielleicht nicht verstanden, das mag sein. Immerhin hat es nicht geklappt.
> Natürlich muss bei Automount im Gegensatz zu Supermount ein Userspace Daemon laufen.
Was ist daran "natürlich"? Ich finde es äußerst komisch, dass ich einen daemon brauche der dann wiederrum dem Kernel sagt was er wann mounten soll. Immerhin braucht auch der Automounter zusätzlich noch einen Kernel-Treiber.
> Und dass dieser Daemon eine Konfigurationsdatei braucht dürfte auch jedem klar sein. > Schliesslich muss der Daemon wissen, welche Devices er wohin mounten kann/soll.
Du kennst Supermount nicht... In der fstab gibt man einfach an, welches device er wohin mounten soll: /mnt/usb /mnt/usb supermount fs=auto,dev=/dev/scsi/host1/bus0/target0/lun0/part1,auto 0 0 Diese Zeile mountet mir meinen USB-Stick nach /mnt/usb mit supermount. Warum muss der automounter mehr Konfiguration brauchen?
Also ich bin grundsätzlich aufgeschlossen gegenüber neuem und auch automount würde mir bei ähnlicher Funktionalität zusagen. Aber wie schon gesagt, ich verstehe das Prinzip nicht. Kannst du mir noch sagen, warum der automounter besser sein soll? Immerhin braucht er mehr Aufwand, da er einen daemon braucht und eine extra Config-Datei und so Scherze. Irgendwas muss daran doch besser sein? Und die Frage ist nicht ironisch gemeint!
Schade, würde mich wirklich interessieren ob es Wert ist, die Doku nochmal zu wälzen...
In diesem Fall ist es mir relativ egal ob es nur unter Linux geht, denn ich habe momentan nur das im Einsatz. :-) Aber da es nur aus einem Kernel-Patch besteht, ist die Wahrschelinlichkeit hoch dass es auch nur mit Linux geht. Ist aber kein Wirklcher Kritikpunkt. Immerhin gibt es recht viele Treiber, die nur unter Linux gehen.
> Also ich bin grundsätzlich aufgeschlossen gegenüber neuem und auch > automount würde mir bei ähnlicher Funktionalität zusagen. Aber wie > schon gesagt, ich verstehe das Prinzip nicht. Kannst du mir noch > sagen, warum der automounter besser sein soll? Immerhin braucht er > mehr Aufwand, da er einen daemon braucht und eine extra Config-Datei > und so Scherze. Irgendwas muss daran doch besser sein? Und die Frage > ist nicht ironisch gemeint!
Ich kenne aus meiner Zeit als Mandrake-User noch Supermount. Ich hatte eigentlich immer gehofft, dass Supermount in den Vanilla-Kernel reinkommt. Bis ich mich dann aber mal mit Automount befasst habe, und heute gefällt mir das eigentlich sehr viel besser.
Was mir aufgefallen ist:
CDs brennen funktionierte bei mir nicht recht, wenn Supermount das Laufwerk eingebunden hatte (ist aber zugegebenermassen schon eine Weile her)
Du kannst bei Automount die Devices nach wie vor normal in /etc/fstab stehen lassen. k3b kann zum Beispiel den CD-Inhalt nicht anzeigen, wenn er das Device nicht mounten kann. Autofs ist danach aber so schlau und bemerkt, dass das Device einen anderen Mountpoint hat, und holt darum selbständig die Daten von da... :-)
> Das einzige was an Supermount nicht passt ist der Samba-Support, das geht noch nicht.
...sollte mit dem Automounter kein Problem darstellen. In /etc/fstab steht dann dein smbfs Eintrag inklusive Mountoptionen ("user=Administrator,password=Ultrageheim" z.B.). In der Automount Konfiguration trägst du dann nur noch den zu überwachenden Mountpoint ein, auf den dein Samba-Share gemountet werden soll.
Sollte mit Supermount eigentlich auch kein Problem sein, nur dass er die Optionen nicht akzeptiert und damit immer ein "permission denied" bringt. Man sollte meinen das wäre einfach zu beheben, aber irgendwie wohl nicht. Naja, egal. Ich braucht mittlerweile gar kein Samba mehr.
yep das wär klasse is halt einfach bequemer das man sich net mehr ums dämliche mount und umount kümmern muss und was soll das auch das man fürs wechseln vonner cdrom nen befehl kennen muss?!
...deswegen bin ich dafür, dass man bei Wechselmedien-Laufwerken komplett auf einen Auswurfknopf verzichtet.
Der Apple machts ja schon seit Jahren (zuerst bei Diskettenlaufwerken inzwischen auch bei CD Laufwerken) erfolgreich vor. Der Anwender wählt "Medium auswerfen" oder drückt einen speziellen Auswurfknopf an der Mac-Tastatur. Im Hintergrund wird dann das Laufwerk unmountet und mit eject ausgeworfen. So etwas könnte man doch sicher auch bei Linux implementieren?
BTW: Zumindest bei KDE muss kein Anwender den unmount oder eject Befehl kennen. Lediglich das CD-ROM Icon anklicken und im Kontextmenü den unmount-Eintrag auswählen und die CD kann ausgeworfen werden.
Ist bei GNOME nicht anders. Nur siehst du dort nur dann ein CD-Icon, wenn eine CD gemountet ist, also wie beim Mac. ;-) Fehlt nur noch, dass man einfach das Icon auf den Mülleimer schiebt, um die CD auszuwerfen.
Das was mir an beidem - Supermount und automount - nicht besonders gut gefällt, ist daß der eingentliche Mount-Vorgang nicht durch den user sondern von root ausgeführt wird. Wenn ich eine Floppy per automount einbinde, gehört sie dem root, und nur der hat dort Rechte. Klar, ich kann in den geeigneten Config-Files Rechte und Owner eintragen, aber die gelten dann _immer_. In einer Multiuser-Umgebung nicht so ganz brauchbar.
Das lässt sich mit Hilfe von uid, gid und umask eigentlich ausreichend lösen. Ich kenne keine Multiuser-Umgebung, bei der alle User auf dasselbe Floppylaufwerk kommen müssen, ist daher ein schlechtes Beispiel...
Für ein Ein-Platz System (für zuhause etwa) gebe ich dir recht. Stell dir aber vor, du willst eine dicken fetten Applikationsserver und eine Reihe reiner X-Terminals betreiben, deren Floppy per network-block-device (NBD) an den Server exportiert wird. Da wär es schon nicht schlecht, wenn die Floppy automatisch eingebunden wird und _nicht_ der neidische Kollege (oder gar der Chef) sofort Vollzugriff darauf hat...
# deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib non-free deb-src http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib non-free
Wenn man das Script /var/lib/dpkg/info/module-init-tools.postrm auf debug stellt (mit set -x), bekommt man bei dpkg --purge drei Links angezeigt, die das Post-Removal-Zeug löschen will und die (zumindest bei mir) nicht existieren. Wenn man die per Hand legt (eines war noch fehlerhafterweise in /bin statt in /sbin) läuft das purge zumindest ohne Errorcodes durch, so dass man die modutils wieder installieren kann. Danach sollte man dann lsmod, depmod und insmod checken. Zu guter Letzt noch ein rm -rf /etc/modprobe* und man ist das alles wieder los.
Ich hatte das post-rm-Script einfach ein exit 0 zurückgeben lassen. Für die modutils bestand dann das Problem, dass die Tools umbenannt waren (*.modutils oder so).. habe entspr. links angelegt. Allerdings jetzt doch wieder die gleichen module-init-tools installiert, weil ich 2.6 noch weiter nutzen möchte. Das Entfernen war nur zum Ausprobieren.
irgendwie bin ich jetzt etwas verwirrt. habe mir den kernel 2.5.71 gezogen. ist das nun der kernel 2.6 oder was passiert mit 2.5.x oder worin liegen die unterschiede?
also: die zweite ziffer sagt dir, ob ein kernel als stabil oder unstabil ist... kernel 2.4.x ist der momentan aktuelle stabile kernel (aktuell 2.4.21). nebenbei wird 2.5 entwickelt, solang, bis er "fertig", also stabil genug ist. dann wird er 2.6.0 genannt und gilt als aktueller stabielr linux kernel... und dann gehts genauso weiter: ein paar entwickler bügeln aus dem 2.6er die (hoffentlich wenigen) bugs raus, es kommt 2.6.1, 2.6.2 usw. und linus torvalds macht einen neuen entwicklerzweig auf, nennt den 2.7.(0) und entwickelt wieder, bis der als stabiler 2.8.0 veröffentlicht werden kann... diese grossen versionssprünge kommen ca. alle 3 jahre... lg, marillchen
Die 2.6-pre sind Testkernel, im Prinzip also 2.5.76, nur dass sie jetzt 2.6-pre heißen, weil kaum noch eine Chance besteht, neue Features einfließen zu lassen.
Dazu Linus himself: The point of the test versions is to make more people realize that they need testing and get some straggling developers realizing that it's too late to worry about the next big feature. I'm hoping that Linux vendors will start offering the test kernels as installation alternatives, and do things like make upgrade internal machines, so that when the real 2.6.0 does happen, we're all set.
Von Micheal Thaler am Mo, 14. Juli 2003 um 15:49 #
Hallo, ich habe fast jede Kernel-Version seit 2.5.69 getestet und ich muß sagen, vor allem der Geschwindigkeitsgewinn auf Desktop-Systemen hat mich sehr beeindruckt. Leider hab ich bis jetzt das Kernel-Module-Autoloading noch nicht richtig zum laufen gebracht. Es scheint sich einiges bei den Modulen geändert zu haben, vor allem wohl das Format der /etc/modules.conf. Unter Kernel 2.4 hat das automatische laden des CDROM-Modules bei Zugriffen auf CDROMs automatisch geklappt, unter 2.5.* und 2.6-test1 funktioniert es nicht. Manuelles einbdingen der Module funktioniert aber. Ausserdem hab ichs nicht geschafft, die pcmcia-cs utils zu kompilieren. make-kpkg beschwert sich modversion.h nicht zu finden (ich glaub, die Datei wars, ich erinnere mich nicht mehr...). Darum läuft auch meine PCMCIA-Netzwerkkarte nicht. Wenn ich das noch zum laufen bekomme, werd ich Kernel 2.6 dauerhaft einsetzen. System: Debian SID mit neuesten modutils
Das Problem mit der fehlenden Headerdatei modversion.h habe ich auch. Es wäre vieleicht interessant, ob es jetzt generell eine andere Vor- gehensweise gibt wenn Module uebersetzt werden solle die nicht im Kernel enthalten ist.Ich denke da vor allem am nvidia und avm-fritzcard.
das Problem mit der modversions.h ist aber relativ alt schon. Ihr müßt die Kernelquellen installieren (bzw. einfach nur nach /usr/src kopieren). Dann geht ihr in das entstandene Verzeichnis (z.B. /usr/src/linux-2.4.irgendwas) und macht dort ein make oldconfig und dann ein make dep, eventuell nur ein make dep. Dann wird die modversions.h erzeugt.
Das habe ich ja auch bislang so gemacht, aber beim 2.6 kommt nach "make dep" der Hinweis, dass dies nicht mehr notwndig ist. Deshalb meine Frage, ob es hier jetzt generell eine andere Vorgehensweise gibt.
Eine ganze Zahl z ist genau dann gerade, wenn sie sich durch 2 teilen lässt, d.h. wenn z/2 ebenfalls eine ganze Zahl ist. 0/2=0 ist eine ganze Zahl, also ist 0 gerade.
Die Null ist Prim (sie lässt sich nur durch null und sich selbst teilen) und daher ungerade, da die 2 die einzige gerade Primzahl ist, muss die null ungerade sein,..
gruss Martin
p.s.: lassst euch von mir nicht auf den arm nehemn,..
Hm... dass man durch Null teilen kann ist mir neu (Nullteilerfreiheit?). Außerdem war die Bedingung für Prim. nicht irgendwie, dass man durch genau 2 verschiedene Zahlen teilen kann. Also müsste 0 != 0 sein, dass Null Prim ist.
Die Null muß gerade sein, denn wenn ich im ganzzahligen Ring der Zahlen jeweils eins addiere oder subtrahiere ändert sich ein Wert immer in den anderen Bereich ( Gerade / ungerade). Da -1 und 1 ungerade sind muß 0 folglich gerade sein.
Die 0 ist in den natürlichen Zahlen nach Konstruktion enthalten. Man setzt nämlich 0 := {} (leere Menge) 1 := {0} = {{}} (Die Menge, die nur die leere Menge enthält) 2 := {0,1} = { {}, {{}} } (Die Menge, die die leere Menge und die Menge mit der leeren Menge enthält) 3 := {0,1,2} 4 := {0,1,2,3} usw...
Insbesondere enthält also jede natürliche Zahl n (als Menge betrachtet) genau n Elemente - nämlich die natürlichen Zahlen, die kleiner als sie sind.
Abgesehen davon geht es bei Vielfachen / gerade/ungerade schon um die ganzen Zahlen, dann die natürlichen Zahlen bilden noch nicht einmal eine echte Gruppe so dass da man da von einer "Rechnung mit Rest" oder Äquivalenzklassenbildung nicht reden kann.
Die 0 ist in den natürlichen Zahlen nach Konstruktion enthalten.
Hm ... dann finde ich es etwas seltsam, daß wir sowohl in der Schule als auch jetzt während des Studiums die "0" immer aus den natürlichen Zahlen raus lassen. Scheinbar gibt es da bei diversen Experten doch keine einheitliche Sicht.
Doch, aber die Umkehrfunktion davon wäre keine. Erst wenn du den Definitionsbereich (der Umkehrfunktion) einschränkst. Ein italienischer Gastschüler war da etwas verwirrt...
So meinte ich das natürlich. Aber der Italiener sah auch Relationen als Funktionen an. Bei uns in Bayern gehört die Null ja auch nicht zu den natülichen Zahlen.
Gabs nicht sogar mal die Überzeugung, daß die 1 ebenfalls keine natürliche Zahl ist? schließlich kann man bis 1 nicht zählen, sondern man braucht mindestens 2 um zählen zu können ?!?
egal, mein Computer fängt bei 0 an zu zählen, schließlich hat das erste Element eines Arrays immer den Index 0, allerdings ist die Länge des Arrays dann schon 1 ?!?
egal, X.0 Releases sind ehh nie stabil, basta. oder war das bei Windows so ?!?
Kenne 2.6.preX nicht, aber unter alsa >0.9 stottert der ice1712 null. Nichtmal unter Last. Entweder ein Mainoard mit kaputtem Chipsatz oder falsch konfiguriert.
Habe unter SuSE 8.2 das Problem, dass generate-modprobe.conf mir einen Befehl "mktemp" mit Parametern ausspuckt -- keine Ahnung, was bei der Übergabe dieses Befehls nicht funktioniert.
Habe jetzt das wichtigste einkompiliert - aber 8139too funktioniert nicht.
Außerdem wichtig: Welche Iptables muss ich nehmene und wo bekomme ich die?
Hallo Habe das selbe Problem mit "generate-modprobe.conf" unter SuSE 8.2. Bis jetzt konnte mir jedoch noch niemand Rat geben. Hast Du unterdessen eine Lösung? Gruss
Habe mal die manpage von mktemp überflogen. Da steht etwas, das mktemp die Angabe der Datei mit sechs angehängeten X haben möchte. In generate-modprobe.conf hab ich den Aufruf `mktemp` in `mktemp $1` geändert, damit mktemp auch etwas übergeben wird. Dann mal generate-modprobe.conf /etc/modprobe.conf.XXXXXX aufgerufen und das Ergebnis nach modprobe.conf umbenannt. Ich bekomme jetzt zwar beim Start mit 2.6.1er Kernel 'nen Haufen Warnings, da aber jetzt meine NIC geladen wird, scheint das Gröbste geschafft zu sein.
Momentan besteht mein "linuxen" in erster Linie im, meisst vergeblichen, Abklappern von Foren und Mailinglisten. Ich hab's dann halt mal mehr dirty als quick probiert. Viele, meist für die Gurus einfach zu banale, Infos sind versteckt, oder gar nicht auffindbar. Da kann einem der Spass an der Sache schon gehörig vergehen und die Frage aufkommen, ob das wirklich alles sein muss. Rechnet man die Stunden in Geld um, so ist der Preis eines weitverbreiteten kommerziellen OS schon lächerlich gering. Dein Dankeschön hat mich sehr gefreut und meine Motivation weiter zu probieren wieder steigen lassen. Jetzt geht es ans aufräumen der modprobe.conf. Schleierhaft ist mir allerdings, warum man in der SDB nichts zu diesem Thema findet.
Von Gabriel Welsche am Di, 15. Juli 2003 um 17:16 #
Hallo, ich kann zwar Module laden und anzeigen lassen (modprobe & lsmod), aber modconf findet keine Module mehr... Weiss jmd., woran das liegen koennte?
Ich hab mir mal die neuen Features mit make menuconfig angeschaut - Wow, wenn das wirklich alles funktioniert wäre der angedachte Sprung auf 3.0 angebracht.
> wirklich alles funktioniert wäre der angedachte Sprung auf 3.0 angebracht.
Ich finde, der Sprung ist nicht so groß. Vieles aus 2.6 ist schon lange in den kerneln der Distributoren enthalten, z.B. O1 sheduler, Alsa, ACPI, cpufreq, lm_sensors, ...
Das meiste anderes neue aus 2.6 ist eher unter der Oberfläche und für Anwender wenig sichtbar.
Grüsse,
Uwe
bis denn,
Martin
Der 3.0er Vorschlag kam übrigens von Linus selber, weil es eben ein großer Schritt war - was daraus wird, wird sich zeigen.
Eine Versionshysterie steht aber wohl nicht an.
wenn ich z.B. eine Datei auf mein Floppy kopiere bleibt der Kopierdialog so lange geöffnet bis die Datei fertig kopiert ist. Danach nehme ich die Diskette einfach aus dem Laufwerk und fertig.
alles andere ist für DAU's einfach zu kompliziert. Habe auch keine Lust mehr immer und immer wieder auf sowas beim Support für Linux Desktopsysteme hinzuweisen.
Disketten mit Linux ist einfach zum k*****, sorry.
Ich arbeite ohnehin lieber mit den mtools an der Konsole. Die schreiben ebenfalls sofort.
Zu supermount:
Solange supermount aktiv war, konnte ich UT2003 nicht installieren.
Nachdem ich supermount rausgeschmissen und manuell gemountet hatte, funktionierte die Installation.
Ich weiß nicht, was ihr für Probleme habt. Man kann das CD-ROM-Laufwerk doch einfach über das Kontextmenü der CD auf dem Desktop aushängen.
Die mtools sind ja wohl nur was für "shellies".
Wozu dann eine grafische GUI mit einem Disketten-Symbol ?
Nee, was mich nervt ist, das das ganze wie nicht/kaum getestet aussieht. Das soll doch u.a. für den "normalen-User" sein. Das Disketten-Laufwerk ist für mich jedenfalls nur noch bedingt benutzbar, jedenfalls unzuverlässig.
Man kann das CD-ROM-Laufwerk doch einfach über das Kontextmenü der CD auf dem Desktop aushängen.
Aber nur solange nicht irgendein Programm/Shell noch irgendwie am CD rumnippelt. Finde ich eh heiss, das mir ein Computer vorschreibt, das ich die CD nicht rausnehmen darf. Ich soll mich dann auf die Suche machen nach einem Programm was vielleicht vor 20 Minuten mal auf die CD zugegriffen hat...
Das gilt aber auch für ein umount auf der Konsole. ;-)
Finde ich eh heiss, das mir ein Computer vorschreibt, das ich die CD nicht rausnehmen darf.
Er bewahrt dich halt davor, ein Medium zu entfernen, auf welches noch zugegriffen wird.
So kannst du auch nicht aus Versehen einen Rohling zerschießen, weil du nicht daran gedacht hast, dass im Hintergrund noch gebrannt wird.
Nur schade, dass sich Disketten nicht locken lassen. Denn wenn man dort async schreibt, und die Diskette zu früh raus nimmt, wars das.
Deswegen hat der Mac auch keinen Auswurfknopf am Diskettenlaufwerk gehabt.
Ich soll mich dann auf die Suche machen nach einem Programm was vielleicht vor 20 Minuten mal auf die CD zugegriffen hat...
Und sei es nur eine Shell in dem jeweiligen Verzeichnis.
Nicht vor 20 Minuten. Irgendetwas greift im Moment auf die CD zu.
So kannst du auch nicht aus Versehen einen Rohling zerschießen, weil du nicht daran gedacht hast, dass im Hintergrund noch gebrannt wird."
Lese und Schreibzugriff sind doch 2 unterschiedliche paar Schuhe. Die Logik dahinter sollte schon intelligent genug sein.
Supermount-NG Soll sehr gut laufen. Falls jemand Mandrake laufen hat : Im Club und AFAIK im mm Kernel ist es drinne.
Gruß
Steffen
Auch ein Programm, das nur lesend auf eine CD zugreift kann abstürzen, wenn Du die CD entfernst bzw. kommt in einen inkonsistenten Zustand. Linux ist halt ein Multi-User OS. Du kannst Dir eigentlich nicht sicher sein, daß niemand anderes im Netz auf die Ressourcen zugreift. OK, bei Dir zu hause vielleicht, aber in einem Firmennetzwerk sieht das halt anders aus. Da liegt in einem Rechner die Telefonauskunft-CD und alle dürfen drauf zugreifen. Blöd ist, wenn die jemand entfernt und Du gerade darauf liest.
a) das Supermount ausschalten (supermount -i disable && remount /mnt/cdrom)
b) ein Image der CD ziehen da sonst das cdrom nicht lange lebt und der Zugriff von der Platte schneller ist ;)
Wir reden hier von Linux als Desktop OS und nicht als Server. Und für ein Desktop OS ist supermount schon sehr wünschenswert. Und da sich Supermount schnell abschalten und anschalten lässt (ergo optional ist) greift dein Beispiel nicht wirklich.
Steffen
Du erklärst, wo du supermount nutzen würdest und wo nicht, wobei man statt supermount auch genausogut automount nehmen kann.
nixname erklärt aber den Grund, dass ein gemountetes Laufwerk gelockt wird.
Auch bei supermount kannst du nicht mitten im Lesevorgang die CD herausholen, was bei Windows aber problemlos möglich ist.
floppy:/
als Adresse angeben.
Gib in den Mountoptionen zusätzlich die Option 'sync' an (das Gegenteil wäre 'async' und ist default).
Gruss - michael
Also ich habe beide ausprobiert. Supermount ist ein Kernel-Patch, sobald der Kernel die Option unterstützt, ist das Teil einsatzbereit und ich kann Volumes mounten.
Den Automounter habe ich nicht geschafft zum Laufen zu bringen. Soweit ich weiss braucht das auch noch einen userspace-daemon der das koordiniert. Jedenfalls habe ich mit Supermount noch nie Probleme gehabt und mit automaout hat es nie geklappt. Vielleicht fehlt mir auch nur die richtige Doku dazu. Alles was ich bisher gefunden habe erklärt das ganz komisch, da muss ich jeden Mountpoint mehrfach anlegen und das automount-Volume liegt dann imemr auf /mnt/auto/... im Gegensatz zu supermount wo ich jedes Gerät auf jeden Mountpoint mounten kann.
Das einzige was an Supermount nicht passt ist der Samba-Support, das geht noch nicht.
Jetzt lästere mal nicht über den automount-Daemon, nur weil du dir die dazu notwenige Dokumentation nicht durchgelesen und/oder verstanden hast.
Natürlich muss bei Automount im Gegensatz zu Supermount ein Userspace Daemon laufen. Und dass dieser Daemon eine Konfigurationsdatei braucht dürfte auch jedem klar sein. Schliesslich muss der Daemon wissen, welche Devices er wohin mounten kann/soll.
Wo wir auch gleich beim nächsten Thema wären: den Mountpoints. Die Mountpoints des Automounters liegen mitnichten fest auf /mnt/auto/* (obwohl sie dort IMHO auch sauber hingehören) sondern du kannst in der Automount-Konfiguration natürlich selbst bestimmen, wohin deine Devices gemountet werden sollen.
Das einzige was zu beachten ist: In /etc/fstab steht der ganz normale Mount-Eintrag. Für jeden Eintrag, der in /etc/fstab vorhanden ist und der über den Automount-Daemon gemountet werden soll, muss zusätzlich ein Eintrag in der Automount-Konfiguratgionsdatei erzeugt werden. Das ist aber auch das einzige, was man als Administrator anlegen muss. Wenn du z.B. Webmin verwendest, kannst du den Automounter wahrscheinlich auch über eine Webschnittstelle administrieren ohne in die Tiefen der Automounter-Syntax abzusteigen.
> notwenige Dokumentation nicht durchgelesen und/oder verstanden hast.
Ich lästere nicht, ich schildere meine Erfahrungen. Gelesen habe ich die Doku schon. Vielleicht nicht verstanden, das mag sein. Immerhin hat es nicht geklappt.
> Natürlich muss bei Automount im Gegensatz zu Supermount ein Userspace Daemon laufen.
Was ist daran "natürlich"? Ich finde es äußerst komisch, dass ich einen daemon brauche der dann wiederrum dem Kernel sagt was er wann mounten soll. Immerhin braucht auch der Automounter zusätzlich noch einen Kernel-Treiber.
> Und dass dieser Daemon eine Konfigurationsdatei braucht dürfte auch jedem klar sein.
> Schliesslich muss der Daemon wissen, welche Devices er wohin mounten kann/soll.
Du kennst Supermount nicht... In der fstab gibt man einfach an, welches device er wohin mounten soll:
/mnt/usb /mnt/usb supermount fs=auto,dev=/dev/scsi/host1/bus0/target0/lun0/part1,auto 0 0
Diese Zeile mountet mir meinen USB-Stick nach /mnt/usb mit supermount.
Warum muss der automounter mehr Konfiguration brauchen?
Also ich bin grundsätzlich aufgeschlossen gegenüber neuem und auch automount würde mir bei ähnlicher Funktionalität zusagen. Aber wie schon gesagt, ich verstehe das Prinzip nicht. Kannst du mir noch sagen, warum der automounter besser sein soll? Immerhin braucht er mehr Aufwand, da er einen daemon braucht und eine extra Config-Datei und so Scherze. Irgendwas muss daran doch besser sein? Und die Frage ist nicht ironisch gemeint!
Allerdings beschränkt sich der Automount-Daemon nicht auf Linux -- oder gibt es den Supermount auch für andere Unix Betriebssysteme?
In diesem Fall ist es mir relativ egal ob es nur unter Linux geht, denn ich habe momentan nur das im Einsatz. :-)
Aber da es nur aus einem Kernel-Patch besteht, ist die Wahrschelinlichkeit hoch dass es auch nur mit Linux geht. Ist aber kein Wirklcher Kritikpunkt. Immerhin gibt es recht viele Treiber, die nur unter Linux gehen.
> automount würde mir bei ähnlicher Funktionalität zusagen. Aber wie
> schon gesagt, ich verstehe das Prinzip nicht. Kannst du mir noch
> sagen, warum der automounter besser sein soll? Immerhin braucht er
> mehr Aufwand, da er einen daemon braucht und eine extra Config-Datei
> und so Scherze. Irgendwas muss daran doch besser sein? Und die Frage
> ist nicht ironisch gemeint!
Ich kenne aus meiner Zeit als Mandrake-User noch Supermount. Ich hatte eigentlich immer gehofft, dass Supermount in den Vanilla-Kernel reinkommt. Bis ich mich dann aber mal mit Automount befasst habe, und heute gefällt mir das eigentlich sehr viel besser.
Was mir aufgefallen ist:
...sollte mit dem Automounter kein Problem darstellen. In /etc/fstab steht dann dein smbfs Eintrag inklusive Mountoptionen ("user=Administrator,password=Ultrageheim" z.B.). In der Automount Konfiguration trägst du dann nur noch den zu überwachenden Mountpoint ein, auf den dein Samba-Share gemountet werden soll.
Also wenn Du's damit nicht schaffst...: CD-ROM und Floppy mittels autofs mounten
Gruss - michael
is halt einfach bequemer das man sich net mehr ums dämliche mount und umount kümmern muss
und was soll das auch das man fürs wechseln vonner cdrom nen befehl kennen muss?!
Der Apple machts ja schon seit Jahren (zuerst bei Diskettenlaufwerken inzwischen auch bei CD Laufwerken) erfolgreich vor. Der Anwender wählt "Medium auswerfen" oder drückt einen speziellen Auswurfknopf an der Mac-Tastatur. Im Hintergrund wird dann das Laufwerk unmountet und mit eject ausgeworfen. So etwas könnte man doch sicher auch bei Linux implementieren?
BTW:
Zumindest bei KDE muss kein Anwender den unmount oder eject Befehl kennen. Lediglich das CD-ROM Icon anklicken und im Kontextmenü den unmount-Eintrag auswählen und die CD kann ausgeworfen werden.
Fehlt nur noch, dass man einfach das Icon auf den Mülleimer schiebt, um die CD auszuwerfen.
Noch nie den PC runtegefahren und wenn er dann aus war festgestellt, daß die CD noch im Laufwerk ist?
Gruss - michael
Mandrake scheint wohl kein besonderes Interesse an einer Aufnahme von Supermount im Standard Kernel zu haben.
Hat es bei der Kombination Fallstricke? Gibt es irgendwo aktualisierte Userspace-Binaries?
Sollte soweit kein problem sein, da die neuen modutils auch mit dem 2.4er arbeiten werden.
bye
# deb http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib non-free
deb-src http://www.fs.tum.de/~bunk/debian woody/bunk-1 main contrib non-free
# Matches:
module-init-tools 0.9.13-pre-0.bunk (i386)
Grüße,
Hosi
Wenn man das Script /var/lib/dpkg/info/module-init-tools.postrm auf debug stellt (mit set -x), bekommt man bei dpkg --purge drei Links angezeigt, die das Post-Removal-Zeug löschen will und die (zumindest bei mir) nicht existieren. Wenn man die per Hand legt (eines war noch fehlerhafterweise in /bin statt in /sbin) läuft das purge zumindest ohne Errorcodes durch, so dass man die modutils wieder installieren kann. Danach sollte man dann lsmod, depmod und insmod checken. Zu guter Letzt noch ein rm -rf /etc/modprobe* und man ist das alles wieder los.
Grüße,
Hosi
http://www.backports.org/debian/
habe mir den kernel 2.5.71 gezogen. ist das nun der kernel 2.6 oder was passiert mit 2.5.x oder worin liegen die unterschiede?
Eremit
lg,
marillchen
Dazu Linus himself:
The point of the test versions is to make more people realize that they need testing and get some straggling developers realizing that it's too late to worry about the next big feature. I'm hoping that Linux vendors will start offering the test kernels as installation alternatives, and do things like make upgrade internal machines, so that when the real 2.6.0 does happen, we're all set.
fs
Eremit
ich habe fast jede Kernel-Version seit 2.5.69 getestet und ich muß sagen, vor allem der Geschwindigkeitsgewinn auf Desktop-Systemen hat mich sehr beeindruckt. Leider hab ich bis jetzt das Kernel-Module-Autoloading noch nicht richtig zum laufen gebracht. Es scheint sich einiges bei den Modulen geändert zu haben, vor allem wohl das Format der /etc/modules.conf. Unter Kernel 2.4 hat das automatische laden des CDROM-Modules bei Zugriffen auf CDROMs automatisch geklappt, unter 2.5.* und 2.6-test1 funktioniert es nicht. Manuelles einbdingen der Module funktioniert aber. Ausserdem hab ichs nicht geschafft, die pcmcia-cs utils zu kompilieren. make-kpkg beschwert sich modversion.h nicht zu finden (ich glaub, die Datei wars, ich erinnere mich nicht mehr...). Darum läuft auch meine PCMCIA-Netzwerkkarte nicht. Wenn ich das noch zum laufen bekomme, werd ich Kernel 2.6 dauerhaft einsetzen. System: Debian SID mit neuesten modutils
$ generate-modprobe.conf /etc/modprobe.conf
Es wäre vieleicht interessant, ob es jetzt generell eine andere Vor-
gehensweise gibt wenn Module uebersetzt werden solle die nicht im Kernel
enthalten ist.Ich denke da vor allem am nvidia und avm-fritzcard.
das Problem mit der modversions.h ist aber relativ alt schon. Ihr müßt die Kernelquellen installieren (bzw. einfach nur nach /usr/src kopieren). Dann geht ihr in das entstandene Verzeichnis (z.B. /usr/src/linux-2.4.irgendwas) und macht dort ein make oldconfig und dann ein make dep, eventuell nur ein make dep. Dann wird die modversions.h erzeugt.
touch /usr/src/linux/include/linux/modversions.h
erzeugt kompiliert zumindest pcmciacs.
Ob ein Kernel stable oder devel ist, entscheidet die zweite Zahl und die 0 ist gerade.
ungrade Zahlen: x=2z+1 (z ist eine ganze Zahl)
0=2*0 w.A.
Ja, denn 0%2 = 0
Eine ganze Zahl z ist genau dann gerade, wenn sie sich durch 2 teilen lässt, d.h. wenn z/2 ebenfalls eine ganze Zahl ist. 0/2=0 ist eine ganze Zahl, also ist 0 gerade.
Platz zum philosophieren gibt es da genauso wenig
(sie lässt sich nur durch null und sich selbst teilen)
und daher ungerade, da die 2 die einzige gerade Primzahl ist, muss die null
ungerade sein,..
gruss Martin
p.s.: lassst euch von mir nicht auf den arm nehemn,..
dass man durch Null teilen kann ist mir neu (Nullteilerfreiheit?).
=> 2 ist nicht die Einzige gerade Primzahl
Wiederspruch
mfg
Zzam
du kanst die null auch durch 3 teilen oder durch 2846 oder x oder was dir sonst noch einfält
Da -1 und 1 ungerade sind muß 0 folglich gerade sein.
Hm ... ist denn der Ausdruck "gerade Zahl" nicht nur auf die natürlichen Zahlen bezogen? Und dort ist die Null ja i.A. nicht enthalten ...
Naja, ist eh' ein bisserl kleinkarriert, oder? Immerhin sollte ein x.0'er Release ja immer stable sein!
Ciao,
Hyperion
Die 0 ist in den natürlichen Zahlen nach Konstruktion enthalten. Man setzt nämlich
0 := {} (leere Menge)
1 := {0} = {{}} (Die Menge, die nur die leere Menge enthält)
2 := {0,1} = { {}, {{}} } (Die Menge, die die leere Menge und die Menge mit der leeren Menge enthält)
3 := {0,1,2}
4 := {0,1,2,3}
usw...
Insbesondere enthält also jede natürliche Zahl n (als Menge betrachtet) genau n Elemente - nämlich die natürlichen Zahlen, die kleiner als sie sind.
Abgesehen davon geht es bei Vielfachen / gerade/ungerade schon um die ganzen Zahlen, dann die natürlichen Zahlen bilden noch nicht einmal eine echte Gruppe so dass da man da von einer "Rechnung mit Rest" oder Äquivalenzklassenbildung nicht reden kann.
Die 0 ist in den natürlichen Zahlen nach Konstruktion enthalten.
Hm ... dann finde ich es etwas seltsam, daß wir sowohl in der Schule als auch jetzt während des Studiums die "0" immer aus den natürlichen Zahlen raus lassen. Scheinbar gibt es da bei diversen Experten doch keine einheitliche Sicht.
Ciao,
Hyperion
Ein italienischer Gastschüler war da etwas verwirrt...
Eine Funktion muss aber nicht eineindeutig sein, um eine Funktion zu sein.
Aber der Italiener sah auch Relationen als Funktionen an.
Bei uns in Bayern gehört die Null ja auch nicht zu den natülichen Zahlen.
egal, mein Computer fängt bei 0 an zu zählen, schließlich hat das erste Element eines Arrays immer den Index 0, allerdings ist die Länge des Arrays dann schon 1 ?!?
egal, X.0 Releases sind ehh nie stabil, basta. oder war das bei Windows so ?!?
ratlose Grüße
Bernd
Probier mal, Alsa 0.9.5 seperat zu bauen.
Den nice-Wert des X-Server von -10 auf 0 setzten.
dpkg-reconfigure xserver-common
so hab ich mir das auch schon oft in den 2.4ern gewünscht.
Und auch make menuconfig ist sehr nett übersichtlich geworden....
yau! >8^)
Habe jetzt das wichtigste einkompiliert - aber 8139too funktioniert nicht.
Außerdem wichtig:
Welche Iptables muss ich nehmene und wo bekomme ich die?
Für Hilfe dankbar,
Gruss!
Bei SuSE8.2 und Mandrake 9.1 darf ich nicht folgenden Befehl ausführen:
chroot /mnt/gentoo /bin/bash
Antwort: "Permission denied".
Weiß jemand Rat?
Wo kriege ich die her, die mod-init-tools ?
Habe das selbe Problem mit "generate-modprobe.conf" unter SuSE 8.2. Bis jetzt konnte mir jedoch noch niemand Rat geben. Hast Du unterdessen eine Lösung?
Gruss
Habe mal die manpage von mktemp überflogen.
Da steht etwas, das mktemp die Angabe der Datei mit sechs angehängeten X haben möchte.
In generate-modprobe.conf hab ich den Aufruf `mktemp` in `mktemp $1` geändert, damit
mktemp auch etwas übergeben wird.
Dann mal generate-modprobe.conf /etc/modprobe.conf.XXXXXX aufgerufen und das Ergebnis
nach modprobe.conf umbenannt.
Ich bekomme jetzt zwar beim Start mit 2.6.1er Kernel 'nen Haufen Warnings, da aber jetzt meine NIC geladen wird, scheint das Gröbste geschafft zu sein.
Viel Erfolg
Peter
Ich hatte das gleiche Problem mit generate-modprobe.conf unter SuSE 8.2, du bist der erste den ich gefunden habe der eine Lösung hatte, great!
Vielen Dank!!!
Gruß Kathrina
Momentan besteht mein "linuxen" in erster Linie im, meisst vergeblichen, Abklappern von Foren und Mailinglisten.
Ich hab's dann halt mal mehr dirty als quick probiert.
Viele, meist für die Gurus einfach zu banale, Infos sind versteckt, oder gar
nicht auffindbar.
Da kann einem der Spass an der Sache schon gehörig vergehen und die Frage aufkommen,
ob das wirklich alles sein muss. Rechnet man die Stunden in Geld um, so ist der Preis
eines weitverbreiteten kommerziellen OS schon lächerlich gering.
Dein Dankeschön hat mich sehr gefreut und meine Motivation weiter zu probieren wieder steigen lassen.
Jetzt geht es ans aufräumen der modprobe.conf.
Schleierhaft ist mir allerdings, warum man in der SDB nichts zu diesem
Thema findet.
Gruss
Peter
ich kann zwar Module laden und anzeigen lassen (modprobe & lsmod), aber modconf findet keine Module mehr... Weiss jmd., woran das liegen koennte?
Gabriel