@malte
@Vain

Darf ich mal ganz doof fragen wie Ihr die Wallpaper bearbeitet habt, dass sie so aussehen?!

Army schrieb @Vain, du sagst also, dass dieses übertriebene Swappen nur unter 32bit auftritt?

Leider nicht mehr. 🙁

Hatte noch eine alte 32-Bit-Installation mit 2.6.39 (2GB RAM, 2GB Swap) „gefunden“ und da mal meinen dd-Testfall ausprobiert. Kein Swapping. Dann Update auf 3.0, aber immernoch kein Swapping. Ich habe das wohl nur am Laptop.

Ich möchte nochmal Wert darauf legen, dass ich keine Probleme habe, wenn ich den Swapspace ganz deaktiviere. Es ist also nicht so, dass der Laptop halt eine schnarchlahme Platte hat, die kein dd und MPD gleichzeitig schafft. Die Musik gerät erst ins Stocken, wenn er anfängt, Prozesse auszulagern. Und das tut er erst, wenn durch Disk Cache der ganze Speicher belegt ist.

Mich wundert, dass swappiness = 0 überhaupt keinen Effekt hat. Sollte das nicht gerade verhindern, dass Disk Cache Programme verdrängt? Oder ist das nur für den umgekehrten Fall, dass Disk Cache bereits belegt ist und eine Anwendung Speicher anfordert (dann bei großer swappiness lieber Programme auslagern und bei swappiness = 0 sofort Teile des Caches verwerfen)?

Also auf gut Deutsch: Ich will, dass Disk Cache auf keinen Fall Anwendungen verdrängt. Ich habe keine „big applications“, die ständig im Hintergrund laufen und sinnlos Speicher belegen könnten. Der Disk Cache soll nutzen, was frei ist, aber sich nicht aktiv mehr Platz verschaffen.

Und er schaut mein Bild an <3

@Vain

Schau dir mal Vimperator an, kann kmpl per Tastatur bedient werden

@hcjl:
die history-datei und die daten daraus hab ich mal gelöscht. bringt leider nichts.

@Vain:
ja, ich glaube ich hab auf beiden shells die gleichen promts mit:

PS1='[\e[0;32m]\u@\h: \w>\e[0m '

ich frag mich gerade, ob es hier nicht richtiger so sein sollte:

PS1='[\e[0;32m]\u@\h: \w>[\e[0m] '

probiere ich gleich mal!

gruß
for_mat_C

Danke für die Antworten 🙂

@Vain

Ja, das mit dem Semikolon hab ich auch grad gesehen, hatte gestern die for-Schleife testweise mal gegen eine while-Schleife getauscht und dann das Semikolon vergessen. Und die Laufzeitvariable ließ sich im Schleifenkopf deklarieren, wenn ich beim kompilieren -std=c99. Aber es ändert sich trotzdem nichts.

@the_isz

Nein, eine Hausaufgabe ist es nicht 🙂 Aber von Zeigern hab ich derzeit weniger (um nicht zu sagen fast garkeine) Ahnung. Trotzdem danke für die Mühe, ist interessant zu sehen, wie es besser gemacht wird.

@Mathematiker

Naja, meine Mathematik-Professorin hat uns nahegelegt, programmieren zu lernen. Weil ich in C schonmal reingeguckt hab und es das Erste war, was mir zwischen die Finger kam, wollte ich es mit C probieren. Aber Python sieht interessant aus, ich werde es mir auch mal angucken.

@Freak1984

Das Levi-Civita-Symbol kenne ich zwar, aber ich wüsste nicht, dass es in C einfach so aufzurufen ist. Oder meintest du auch Python?

Wenn ich mich nicht total verrechne, dann ist das Ergebnis immer um eins zu hoch.

Komponente a_0: 1
Komponente a_1: 1
Komponente a_2: 1

Komponente b_0: 1
Komponente b_1: 1
Komponente b_2: 1

Komponente c_0: 1
Komponente c_1: 1
Komponente c_2: 1

a * b = 3.00
a x b = (0.00,0.00,0.00)
(a x b) * c = 1.00

Wenn ich aber immer wieder nach der Zuweisung einmal den Wert der Variablen ausgeben lasse, dann erhalte ich anscheinend das richtige Ergebnis:

/*Kreuzprodukt speichern*/
	for(i = 0; i <= 2; i++) {

		erg_kreuz[i] = kreuz(a_1,a_2,a_3,b_1,b_2,b_3); printf("%.2lf\n", erg_kreuz[i]);
		
	}

Wenn ich mich nicht total verrechne, dann ist das Ergebnis immer um eins zu hoch.

Komponente a_0: 1
Komponente a_1: 1
Komponente a_2: 1

Komponente b_0: 1
Komponente b_1: 1
Komponente b_2: 1

Komponente c_0: 1
Komponente c_1: 1
Komponente c_2: 1

0.00
0.00
0.00
a * b = 3.00
a x b = (0.00,0.00,0.00)
(a x b) * c = 0.00

Das verstehe ich nicht, weil ich dachte, Variablenwerte ausgeben ändert diese Werte nicht.

@Vain

Ich denke, du hast recht und ein kompletter Downgrade wäre nicht die optimale Lösung. Werde also erstmal warten...

Vain schriebIch bin mir aber ehrlich gesagt auch nicht sicher, ob das jetzt ein Bug in libtiff oder libjpeg8 ist. Hat sich das Problem eigentlich sonst mal einer angesehen? Oder sollte man einfach mal 'nen Bug bei Arch aufmachen, um mehr Meinungen zu sammeln?

Das habe ich mich auch schon gefragt, ob es an libtiff 3.9.2-2 oder libjpeg 8-2 liegt. Es scheint aber schon seit über zweieinhalb Wochen bekannt zu sein, daß es nicht funktioniert aber kaum einer Meldet sich dazu. Sicher, wann wird schon mal ein Bild von jpeg nach tiff gewandelt oder wer scannt schon Dokumente und legt sie als tiff ab? Wird sicherlich auch den wenigsten bewußt sein, daß es nicht funktioniert...

Naja, ein kleiner Programmierfehler mit großer Auswirkung 😉

Gruß,

Thorsten