Linux, Fedora 16: How to turn Advanced Power Management less aggressive (only if you really afraid about your hard disk)

Some people hear a click-clack noise while working on their notebooks running linux. The reason was found to be a too aggressive power management which could cause the hard disk die prematurely. Here is an article about this problem and possible solutions (in german): “Linux User” 2012-01 “Bund fürs Leben” page 66 ff..

On a ASUSTeK Computer Inc. notebook model A54C (see last recent article in this blog) which comes with an “Seagate Momentus 5400.6 / ST9320325AS” hdd and runs Fedora 16 I decided to turn down the power mangament. There was no need for it (see this recent article). I just see no sense in a aggressive power management since I use to work when notebook is on power and switch it off when finished working. Furthermore, aggressive power management was used when the notebook runs on AC!

The Advanced Power Management was set to 128 by SMART software (that means by the hdd itself). I found this by executing:

$ sudo hdparm -I /dev/sda | grep “Advanced power management”

    Advanced power management level: 128

The value can range between 1 (= VERY agressive) and 255 (Advanced Power Management off). I decided to reduce it to 240. Don’t ask why this value – I just guessed. One one hand I want the hard disk to be capable to do some Advanced Power Management but I dont want it to be agressive. I avoided a value of 254 because someone observed his hdd running hot.

To have the change permanently we need to set it again after each power-off (I observed that this change was still available after reboot). _This is done by placing a command into the file /etc/rc.d/rc.local and run it as root. Running as root is done in my solution by setting the “s-bit” for the /etc/rc.d/rc.local (for the user only, the file is owned by root of course). (The s-bit is a flag which allows a program to run with the rights of it’s owner.)

This are the steps I made to change the level of Advanced Power Management permanently (lines starting with $ means that I typed a command into terminal, lines without $ right below tell what the command print out):

1) Looking for file /etc/rc.d/rc.local:

$ ls /etc/rc.d/rc.local

ls: cannot access /etc/rc.d/rc.local: No such file or directory

/etc/rc.d/rc.local didn’t exist.

2) Find out how your hard disk(s) is (are) mapped. If you have only one hard disk in your computer it should be mapped as “/dev/sda”. Launch GSmartControl to check. I can see two drives:

  (A) “ST9320325AS” (text following “Drive information” starts with “/dev/sda”)

  (B) “CDDVDW SN-208BB” (text following “Drive information” starts with “/dev/sr0″)

Drive (A) is the hard disk. I did not try this with external drives!

3) Create a file named rc.local in your home folder. Use you favorite text editor e.g. Acessoires -> gedit for it. Put this two lines in the file (if your hard disk is mapped on “/dev/sda” otherwise replace “/dev/sda” by the mapping for your hard drive!!!):

#!/bin/bash

hdparm -B 240 /dev/sda

“240″ is the level of Adavanced Power Management you wish. Please note the the command “hdparm” could kill your hard disk if used without knowledge. Thus I use the -B parameter with values greater than the default value only.

4) Open a terminal e.g. System -> Terminal and change into the folder there the file exists.

5) Give the file the proper owner and read-write-execute rights. Note that we need :

$ chmod 755 rc.local

$ chmod u+s rc.local

$ chown root:root rc.local

6) Now check the file. Mine looks like:

$ ls -l rc.local

-rwsr-xr-x. 1 root root 36 May  2 23:12 rc.local

7) Now copy this file into the folder where it will run when the machine boots. This command ask for the root password (the paasword you use to change something on the operation system e.g. install a printer):

$ sudo cp rc.local /etc/rc.d/

8) Reboot your machine.

9) Check if it has effect:

$ sudo hdparm -I /dev/sda | grep “Advanced power management”

    Advanced power management level: 240

If you want to try it just until next power-off:

$ sudo hdparm -B 240 /dev/sda

Check as written above.

—

With this value I observed counting the value of “193 Load / Unload Cycle” (by GSmartControl) in 41 hours from 1080 to 1102. I could not observe any effect on battery runtime. This notebook (Asus A54C on Fedora 16) runs still 2 hours on battery. In opposite, turn down screen brightness has an effect on runtime for sure. One could also switch off wireless network if not needed (See installation report for Dell Latitude E4300 in this blog).

=-=-=-=-=
Powered by Blogilo

Goodbye Ubuntu, hello Linux Mint (Debian Edition)!

Es musste einfach sein: Genervt durch einen Bug, der dazu führte dass Linux abstürzte wenn ich ein Flash Video mit dem Adobe Flash Player abspielte wollte ich wissen ob das nur mit dem Flas Player (mit Gnash passierte das nicht, aber Gnash kann auch keine Flash Videos der Version “AVM” abspielen) zu tun hat oder ob auch Ubuntu ein Problem hat. Also probierte ich auf meinem Zweitnotebook Fedora aus – das war aber nicht nach meinem Geschmack, schon bei der ersten Aktualisierung gab es Fehlermeldungen. Also probierte ich mal das im Linux User gelobt Linux Mint – und zwar in der Debian Edition! Erster Eindruck: Der zieht aber eine Menge Updates. Zweiter Eindruck: Läuft stabil, alles an Board, sogar Flash Video *) geht. Dritter Eindruck: Das nehme ich!

Zu dieser Entscheidung trug auch bei, dass ich nicht weiß wie es bei Ubuntu mit Gnome weiter geht. Ich möchte nicht plötzlich eine unbekannte Oberfläche installiert bekommen, mit der ich vielleicht nicht richtig arbeiten kann.

Jedenfalls habe ich mich kurzerhand beschlossen, Linux Mint Desktop Edition (LMDE) auch gleich meinen Eltern auch ihren PC zu installieren. Dass ich ihr Windows XP de- und Linux installiere war bereits vor einiger Zeit ausgemacht, weil beide mit der Administration von Windows XP etwas überfordert waren und ich zu selten Zeit habe das zu tun. Mit LMDE gibt es keine Probleme mehr. Ich kann per Fernzugriff remote-Unterstützung bieten und habe ihnen das System genauso konfiguriere wie sie es brauchen, nämlich einfach. Das klappt wunderbar! Die updates machen sie nicht selbst, das tue ich von Zeit zu Zeit. Da der Rechner nur als Textverarbeitung und zum Surfen benutzt wird, sollte das OK sein, denke ich.

Wenn ich noch mal umsteige, dann auf Debian Testing oder Unstable.

*) Es wird höchste Zeit dass es einen frei implementierbaren Standard gibt, der von jedermann in seinem Browser implementiert werden kann. Es muß ja nicht das allerbeste Pferd im Stall sein, aber etwas brauchbares – und bitte patentfreies!

How to get Apache Maven to build scala projects?

How to get Apache Maven to build scala projects?

Download the file gol3.zip from [5] (at the very end of the page) and unpack the contained pom.xml. Make it to your pom.xml by adapting it to your project. The go to [1] and copy+paste the part for surefire plugin into your pom.xml and the import and @RunWith in your scalatests.

The full story

If you google for that, you’ll most probably find [1] and [2]. But both ([2] is an refrence to [1]) failed. Of cource i copied the needed import and @RunWith in my scalatests and compiled them. The error was:

Without surefire plugin: Not tests are found

With surefire plugin:

…
[INFO] ————————————————————————
[ERROR] FATAL ERROR
[INFO] ————————————————————————
[INFO] scala/ScalaObject
scala.ScalaObject
[INFO] ————————————————————————
[INFO] Trace
java.lang.NoClassDefFoundError: scala/ScalaObject
…

This affected also others (Thanks to Kenneth McDonald for asking in [3], [4] and [5]).  The key to the solution was found by Nayan Hajratwala in the Apache Maven forum [5]: He gave us in his last answer on this thread a file named gol3.zip. It containes a pom.xml which – as it is – no tests found. But i realised that the surefire plugin was missing! So i added the tag for the surefire plugin from [2] – AND IT WORKS!!! Thanks so much!

Examples_for_working_pom_xmls

Testcases wich works with this pom.xmls:
http://decisiontable.sourceforge.net -> DecisiontableLib
http://myflipflops.sourceforge.net -> Toolbox

[1] JPZ’LOG ScalaTest in Maven

[2] Is there a Scala unit test tool that integrates well with Maven?

[3] Closer, but still problems with maven an scalatest

[4] Still problems with IDEA/maven/scala test phase

[5] Problems with Scala unit testing

PS: At the very end i decided to use Gradle for my scala builds. Although i got Maven to run and read 50% of  “Maven by example” and “Maven complete reference” provided by sonatype, the company behind Maven, i found Gradle easier to handle.

Update auf Ubuntu 10.10

Scala: Es ist immer noch Version 2.7.7 installiert -> stört mich nicht

JEdit (1): Erst böses Erwachen, dann Erleichterung: Einige Buchstaben im Textbereich (also da, wo mein Code steht) haben zusätzlich farbige Striche, wo keine Striche hingehören. Ein “r” sieht so immer ein bisschen wie ein “n” aus, auch “a” und “e” haben sog. Artefakte. Nach einigem Probieren fand ich die Lösung: Ich hatte das Aliasing war auf “subpixel” eingestellt! Mit “standard” war das Problem behoben: Utilities -> Global Options -> im Fenster “Options” den Eintrag “Text Area” auswählen und in “Anti Aliased smooth text” den Wert “standard” auswählen.

JEdit (2): Die Tooltips, die bei Start angezeigt werden, finden einen Ordner nicht mehr: Help -> Tip of the day -> “doc/tips directory not found”. Nicht weiter schlimm, behebe ich später.

JEdit – Spaß mit Tabs Leerzeichen

Eigentlich hatte ich mir JEdit über Utilities -> Global Options -> Editing wie unten zu sehen eingerichtet. Mit “Soft … tabs” = “Aus” wollte ich vermeiden, dass Tabs in Leerzeichen umgewandelt werden.

Mit Textdateien klappte das prima, aber .scala – Dateien wurden beim Öffnen immer in diese Einstellungen zurückgesetzt (zu sehen in Utilities -> Buffer Options):

Grübel … Wieso nimmt JEdit ausgerechnet für Scala die Originaleinstellungen?

Lösung: In der Datei “~/.jedit/modes/scala.xml” (“~” steht in Pfadangaben auf Unix-Systemen immer für Ihr Homeverzeichnis) findet sich dieser Eintrag:

PROPERTY NAME="tabSize" VALUE="2"

PROPERTY NAME="indentSize" VALUE="2"

Da sind ja die “falschen” Einstellungen. Das Ganze geändert zu:

PROPERTY NAME="tabSize" VALUE="4"

PROPERTY NAME="indentSize" VALUE="4"

und schon sind bleiben die Einstellungen wie sie sollen:

Geht doch. Die Erweiterung für Scala speichert also eigene Einstellungen für die Feinheiten der Textdatei.

Scala: Import von Klassen funktioniert mit Version 2.8.0 nicht, wenn

man Scala 2.8.0 auf den Rechner kopiert hat und den Klassenpfad nicht entsprechend setzt – jedenfalls ist das meine Vermutung. Der Reihe nach:

- JEdit macht sich prima, aber die Farben der Syntax-Hervorhebung im Editor – grausig. Ich ermüdete sehr schnell. Die Rettung ist das PlugIn “Editor Scheme Selector” Das MUSS man einfach haben! Es zeigt einem (nachzählen) 25 verschiedene, geschmackvolle Farbschemas für den Editor an. Es sind welche mit hellem und dunklem Hintergrund darunter. Mein Lieblingsschema heißt “Dessert”.

- Ich habe mir auch das Console-PlugIn (nebst 10 anderen, wie Hex Edit, JDiff PlugIn, SVN PlugIn, Whitespace u.a.) installiert. Damit kann ich die gerade offene Datei kompilieren.

Leider habe ich als Pfad zum Scala-Kompiler ein Verzeichnis angegeben, in das ich Scala-2.8.0 entpackt hatte. Die Folge war, dass ich ich nur noch Klassen kompilieren konnte, die keine anderen Klassen importierten! Ich habe den Fehler natürlich ewig in meinem Code gesucht, bis ich die richtige Idee hatte. Ich benutze seitdem wieder den Scala-2.7.7-Kompiler aus den Ubuntu-Repositories und Klassen mit import (lokaler Klassen) kompilieren wieder fehlerfrei.

Nun kann ich eine shell öffnen und los kompilieren:

- in das Verzeichnis “src” wechseln (man sollte die Quellcodedateien getrennt von den kompilierte Dateien, den sog, binaries halten, daher der Ordner “src”. Auf derselben Ebene sollte es einen Ordner “bin” geben.)

- “scalac -d ../bin pfad.zu.meiner.Klasse.meineKlasse.scala” aufrufen

Mit dem PlugIn Console könnte ich auch direkt aus JEdit heraus kompilieren, würden dem unter (Ubuntu-)Linux nicht drei ernste Problem mit dem Scala-Toolkit für JEdit im Weg stehen:

(1) Der vorgegebene Pfad zum Scala-Kompiler (und zum Interpreter) ist für Nicht-Windowssysteme “/usr/local/scala” – Auf Ubuntu ist Scala unter /usr/bin/ installiert (und auf anderen Linuxen bestimmt auch). Dieser Pfad kann durch die Variable $SCALA_HOME überschrieben werden aber durch (3) wird aus “/usr/bin” immer “/usr/bin/bin”!

(2) scalac und scala werden mit der Option -classpath aufgerufen, wenn in der Maske (die sich nach Rechtsklick auf den Editor und “Compile Current Buffer …” öffnet) im Feld “Classpath” ein Pfad eingetragen ist. Diese Option sorgte bei mir dafür, dass das Kompilieren mit einem Fehler endete. Und es ist immer ein Pfad eingetragen, wenn man die Maske aufruft. Also müsste ich dieses Feld immer leeren.

(3) an den Pfad zum Scala-Kompiler wird für Nicht-Windowssysteme immer “/bin” angehangen

Ich habe also in den Dateien scala.xml und scalac.xml aus dem Ordner “scala-2.8.0.final.zip/misc/scala-tool-support/jedit/console/commando” folgende Zeilen geändert (Zeilennummern wie scalac.xml, scala.xml enthält diesselben Zeilen, die genauso zu ändern sind):

(1) Zeile 44

war value = (isWin32) ? "c:\\\\Progra~1\\Scala" : "/usr/local/scala";

ist value = (isWin32) ? "c:\\\\Progra~1\\Scala" : "/usr/bin";

(2) Zeile 53

war <DIR_ENTRY LABEL="Class path" VARNAME="classpath" EVAL='buffer.getDirectory()'/>

ist <DIR_ENTRY LABEL="Class path" VARNAME="classpath"/>

(3) Zeile 60

war if (home.length() > 0) buf.append(home + File.separator + "bin" + File.separator);

ist if (home.length() > 0) buf.append(home + File.separator);

Jetzt passt alles: Rechtsklick –> Compile Current Buffer:

Scala Home Path = “/usr/bin”

Source File(s) = die gerade offene Datei

Class Path = leer

Output Directory = das zuletzt gewählte Verzeichnis

Jetzt “OK” klicken und schon öffnet sich eine shell in der ich mir das Ergebnis in Ruhe ansehen kann…

Eclipse 3.5.2, 3.6 und Netbeans 6.8, 6.9.1: Scala-PlugIns noch nicht ausgereift – JEdit beeindruckt

Scala-PlugIn für Eclipse 3.5.2, 3.6: Der Scala-Editor funktioniert wunderbar, aber es lassen sich keine JUnit4-Tests für Scala erstellen – diese Option wird nur für Java angeboten. Die so erzeugten JUnit4-Tests lassen sich nur mit Java schreiben – sie haben ja auch die Endung .java

Scala-PlugIn für Netbeans 6.8, 6.9.1: Der Scala-Editor funktioniert wunderbar, man kann JUnit4-Tests für Scala erstellen – aber diese Tests (im Ordner test/) erkennen die Scala-Klassen aus dem Ordner src/ (auf derselben Ebene) nicht. Die Syntaxvervollständigung (im JUnit-Test “import .” tippen und schon sollten Vorschläge für die zu importierende Klasse kommen) behauptet sogar, die Klasse sei leer. Das Einfügen von “_root_” in den Klassenpfad hilft nicht. Das Erstellen der JUnit-Tests in Ordner src/ hilft auch nicht, denn dann wird “junit” nicht als Klasse von “org” erkannt (“import org.junit._”)

Scala-PlugIn für IntelliJ: Nicht getestet, nachdem ich die negativen Kommentare einiger Benutzer auf der Website des Scala-PlugIns gelesen habe.

Wie gesagt ich arbeite mit Ubuntu 10.04.

JEdit (aus den Ubuntu-Repositories) überrascht dagegen mit einer viel besseren Darstellung (als Ende 2008), andockbaren Fenstern, einer shell(!) und zahlreichen nützlichen, funktionierenden PlugIns! Ich habe mir JUnit4 und Scalatest als zip von den jeweiligen Webseiten geladen und die Installationspfade zu einer Variable namens $Classpath hinzugefügt (“export Classpath:$Classpath::” siehe FAQ zu JUnit.) Ob es mir gelingt, JUnit-Tests für Scala (a) überhaupt und (b) vielleicht sogar mit dem JEdit-JUnit4-PlugIn zum laufen zu bringen? Wird JEdit reichen, um ein Projekt zu machen? Ist es vielleicht sogar die bessere IDE?

Wie kriege ich das Scala-PlugIn in Netbeans zum Laufen?

Es war entmutigend: Ich habe alles gemacht, wie es die Anleitung vorschreibt:

- Scala + Netbeans installiert (schön aus den offiziellen Ubuntu – Paketquellen)

- die Schritte in http://wiki.netbeans.org/Scala befolgt (wobei mir das Installationsverzeichnis von Scala (/usr/bin für das binary bzw. /usr/share/java für die jar-Datei) komisch vorkamen, weil es dort keinen Unterordner /bin gibt)

Ich wußte, dass ich nicht wie vorgeschrieben Scala 2.8.0 sondern 2.7.7 installiert hatte, hielt das aber nicht für schlimm

Jedenfalls kam beim Ausführen von Scla-JUnit-Tests immer die Fehlermeldung

Could not load definitions from resource scala/tools/ant/antlib.xml. It could not be found.

init:

deps-jar:

/home/…/NetBeansProjects/ScalaLibrary2/nbproject/build-impl.xml:403: The following error occurred while executing this line:

/home/…/NetBeansProjects/ScalaLibrary2/nbproject/build-impl.xml:236: Problem: failed to create task or type scalac

Cause: The name is undefined.

Action: Check the spelling.

Action: Check that any custom tasks/types have been declared.

Action: Check that any / declarations have taken place.
ERSTELLEN FEHLGESCHLAGEN (Gesamtzeit: 0 Minuten 0 Sekunden)

Um es kurz zu machen: Wenn man sich von http://www.scala-lang.org/downloads das Scala-Päckchen für Linux herunterlädt und entpackt sieht man sofort viel mehr Dateien als in den o.g. Pfaden, u.a. einen Ordner namens “/bin”. Daraufhin habe ich mir auch Netbeans für Java SE (die einfachste Variante von Netbeans) als systemunabhängiges Paket (netbeans-6.9.1-201008030030-ml-javase.zip) und das Scala-PlugIn für Netbeans nb-scala-6.9v1.1.0 herunter geladen und alle drei Pakete entpackt.

Ich habe dann Netbeans 6.9.1 und Scala 2.8.0 in einen Ordner unter /home/ verschoben und Eigentümer/Gruppe/Rechte geändert + kontrolliert (-> Sicherheithinweis am Ende des Blogs!), die Variable $SCALA_HOME auf den Ordner mit Scala gelegt sowie $PATH um $SCALA_HOME/bin erweitert. Dazu bekam die Datei /etc/profile folgenden zusätzlichen Text am Ende angefügt:

SCALA_HOME=/home//scala-2.8.0.final
export SCALA_HOME
PATH=$PATH:$SCALA_HOME/bin
export PATH

Danach muß man sich ab- und anmelden, damit die neuen Variablen funktionieren. Jetzt wird Netbeans gestartet: /home//netbeans/bin/netbeans
Bei mir meldete sich wine mit einer Fehlermeldung, aber das machte nichts.

Das Scala-PlugIn für Netbeans nb-scala-6.9v1.1.0 wurde wie in der Installationsanleitung des Plug-Ins beschrieben installiert. Nun funktioniert alles! Wenn ich aus der shell “scala” aufrufe, kommt das über das Paketsystem installierte Scala 2.7.7. Für die Beispiele aus “Programming in Scala” (ohne dieses Buch findet man meiner Meinung nach nur schwer Zugang zu Scala) reicht das.

Diskussion der Installationsmethode für Linux-Anfänger:
Eine der besten Dinge an Linux sind die “offiziellen Paketquellen”. In Linux ist es Prinzip, das alle verfügbare Software, wo immer die Lizenz es zulässt, vom Hersteller der Distribution an einem Platz im Web zur Verfügung gestellt wird. Das sind die “offiziellen Paketquellen”. Will man eine Software installieren, ruft man ein Programm (z.B. Ubuntus Software-Center) auf, sucht sich seine Software aus und und installiert sie mittels dieses Programms (dahinter steht das sog. Paketsystem). Dieses Programm merkt sich auch gleich wo was installiert ist und kümmert sich fürsorglich um die updates! Das funktioniert sogar für den innersten Kern des Betriebssytems.

Normalerweise sollte man Software nur mit Hilfe des Paketsystems und nur aus “offiziellen Paketquellen” instllieren, aber man kann auch Ausnahmen zulassen. Eine meiner Meinung nach sehr sinnvolle Ausnahme sind Entwicklungsumgebungen. Wenn man einen zweiten Perl-Interpreter mit den zugehörigen Perl-Modulen (z.B. von Active State) installiert, hat das den Vorteil, das man die neuesten Versiondes Interpreters oder der Module einspielen kann, ohne das Betriebssystem (das seinen eigenen Perl-Interpreter mit eigenen Modulen hat) zu beeinflussen. (Die Softwarestände innerhalb der Distribution sind sorgfältig aufeinander abgestimmt. Je länger eine Version in Gebrauch ist, desto geringer ist die Wahrscheinlichkeit, das neue(!) Bugs auftauchen. Deshalb dauert es meistens etwas bis eine neue Version in die offiziellen Paketquellen gelangt). Sonst kann es passieren, dass man das Betriebssytem durch Basteleien an der Entwicklungsumgebung beeinträchtigt.

Mann kann Software sogar in das eigene Homerverzeichnis installieren (dann aber unbedingt auf Rechte und Eigentümer achten!!!), dann kann jeder Benutzer seinen eigenen Softwarestand haben. (Als Anfänger sollten Sie vielleicht lieber /opt/ benutzen.)

Wenn man die Software in das Homeverzeichnis installiert, dann aber dafür sorgen, dass der Eigentümer der Benutzer “root” und die Gruppe “root” sind! Es gibt bereits malware, die Entwicklungsumgebungen infiziert um sich mit den dort entwickelten Programmen zu verbreiten! /opt/ erscheint mir sicherer, aber /home/ ist bequemer. lasse mir Eigentümer und Rechte zur Sicherheit noch einmal anzeigen.