Porteus vom usb

Saturday, December 29. 2012

Schnell ist es ja. Wenn auch nur beim Booten.
In kaum einer Minute vom Einschalten bis in den KDE-Desktop (Trinity ~KDE 3.5), und das auf einer alten acer Travelmate 4060-Büchse ohne HD von einem 0815-usb. Und dabei sind mindestens 5, vllt aber sogar 15 sec. warten auf ein Timeout noch inklusive - das ist aber deutlich was schneller als der vorige Anlauf mit Mint.
Wenn man es erst mal zum Starten gebracht hat, und auch danach gilt: holp'rige Wegstrecke.

Porteus ist Kindeskind von Slackware, graue Eminenz der Distributionen. Meine erste Linux-Installation war ein Slackware, stilecht auf einem 386SX so circa 1997. Linux zu installieren war damals eine ziemlich frustrierende Angelegenheit, um es vorsichtig auszudrücken. 

Porteus sagt von sich, eine Distribution zu sein, die darauf optimiert ist, von Medien wie einem USB-Stick sehr schnell zu booten. Wie bringe ich Porteus bootfähig auf einen Stick? Da ist die Doku ganz klar: 

  • .iso herunterladen, auf cd brennen
  • Rechner von der CD-Rom nach Porteus booten
  • usb-Stick einstecken
  • Porteus Installer machen lassen

Fein, dass mit dem neu booten übertrage ich einer vbox - vm aber davon ab folge ich der Anleitung wortwörtlich. Ergebnis: geht nicht.
Den Reminder angeklickt und Bootloader installieren ausgewählt, das Ding (ziemlich lange) machen lassen, bis es mir Erfolg meldet und dann den Laptop vom stick booten - und er benimmt sich, als sei überhaupt kein boot loader vorhanden. not a bootable disk.

Aus seiner Vorgeschichte misstraue ich dem stick etwas und formatiere ihn (vfat) neu. Wiederhole die vorigen Schritte, hat nichts geholfen.
Kurz gegoogelt und die Sache zu Fuss unternommen. 
Ja, hagelt es eine Ladung roter Fehler, md5 hash fail. Google drauf, finde http://forum.porteus.org/viewtopic.php?f=41&t=1378
K
urzversion: am 10.7.2012 bestätigt der Guru dieser Distri, dass er da in der Datei md5sums.txt irgendwie die falschen Pfade erwischt hat. 
Mein Download war am 28.12, satte 5,5 Monate später, und der bestätigte Bug ist unverändert drin. 

Der empfohlene workaround war ohnehin, die roten Fehler schlicht zu ignorieren unde weiter zu machen. Was ich auch tat, nur um nun beim nächsten Bootversuch Fehler analog dieser Beschreibung zu bekommen:

 

SYSLINUX 4.04 CHS 2011-04-18 Copyright (C) 1994-2011 H. Peter Anvin et al
ERROR: No configuration file found
No DEFAULT or UI configuration directive found!
(bei mir war es SYSLINUX 4.05)
 
Der Poster meldet am Ende des Threads, er sei nun darauf gekommen, dass Syslinux auf seinem Rechner fat-32 nicht erkennt, mit fat-16 ging es. Fat-16 war mir nun wirklich zuviel an Erniedrigung aber ich beschloss, seinen Tip doch aufzugreifen und meinen Stick mal wieder neu zu formatieren, zur Abwechslung mit ext3. Anschliessend /boot und /porteus vom .iso auf den Stick kopieren, den Bootloader mit 
/boot/lin_start_here.sh
installieren, Test-Boot und Bingo!, auf einmal kommt die Kiste hoch. Sauschnell, siehe oben.
 
Ländereinstellung (deutsches Tastatur-Layout) sind nicht von einer Sitzung zur nächsten persistent.
Trinity hält sie aber wenigstens während der laufenden Session bei, während unter LXDE das US-Layout schon nach wenigen Mouseclicks wieder zurückkehrt. Porteus-Settings nimmt sich desbezüglich einige Zeit, ändert letztlich aber gar nichts am Ablauf.
 
Nur Google aus dem Network-Package zu installieren geht schief. Es kommt (kurz)= eine MsgBox mit einem Hinweis auf Misserfolg beim Anlegen des Profile und dann segfaults Chrome. Mit dem mc im Dateisystem herumspazierend fallen mir dann diverse zerbrochene Symlinks unter / auf libs unter /usr/lib/seamonkey auf. So sensibilisiert entdecke ich im Network-Package dann die Seamonkey shared libs, die aktiviert und auf einmal geht Google Chrome auch. 
Unter LXDE schafft es Google-Chrome mehrfach nicht, die Settings mit dem Google-Account zu synchronisieren, das ding lädt und lädt und lädt... Zurück auf Trinity/KDE klappt es aber.
 
Also im ersten Eindruck: mehr als nur ein paar ungeschliffene Ecken sind schon dabei...
 

 

 

 Vor bald schon drei Jahren habe ich das Verhalten der ISP zu IPv6 albern genannt. Das war in der Zeit der Counter auf das Auslaufen verfügbarer IPv4 - Adressen bei der IANA. Das ist nun schon graue Vergangenheit, IANA steht seit dem 3.2. 2011 auf 0 und inzwischen stehen APNIC (Asien/Pacific) und RIPE (Europa) mit 17, 18 Mio restlicher legacy IPs am dichtesten an der Kante. Oder noch weniger, Ripe hat jedenfalls am 14.9.2012 die letzte Schnitte ausgerufen.
Da rast der Zug also mit relativ vorhersehbarem Tempo auf's Gleisende zu.

Und bei den ISPs? Fast alles wie gehabt, mein Anruf bei der Alice-Hotline erwischt den Mitarbeiter dort auf dem falschen Fuss, weil er mit dem Begriff IPv6 grade nichts zu verbinden weiss. Gelegentlich findet man in Foren einen Beitrag von ISP-Mitarbeitern, die versichern, das Kundeninteresse im Auge IPv6 zeitnah einführen zu wollen, beharrliches Quengeln stösst auf nichts als Ausreden.
Kabel-anbieter (Kabel Deutschland, Kabel BW) geben IPv6, aber selbst wo es technisch möglich sein sollte, kann man sie nicht unbedingt bekommen. Ich zum Beispiel; auf der anderen Strassenseite ist Kabel Deutschland verfügbar aber ich wohne in einem Block, der bei irgendeiner undurchsichtigen Aufteilung von Interessensgebieten der seinerzeitigen Fernsehkabelanbieter einem anderen Oligopolisten zugeschlagen wurde.  

Aber jetzt gibt es wirklich mal Bewegung: angeblich seit September richtet die Telekom für Neukunden-anschlüsse Dual Stack ein. Neukunden heisst: das gibt es nur für sg. NG-Anschlüsse (bei denen die Telefonie letztlich via VOIP umgesetzt ist.)

Altkunden und Leute, die gern ihren ISDN-Anschluss (der auch bei Stromausfall noch funktioniert und mit Fax keine Probleme macht) behalten wollen, kriegen es aber nicht.  

Einen Überblick über den (Still)Stand bei den ISPs gibt Lutz Donnerhackes Artikel auf 
http://lutz.donnerhacke.de/Blog/IPv6-Wo-stehen-wir-im-Plan

Und, ergänzt aus Thomas Schäfers Kommentar (unten) noch eine interaktive Browser-Statistik. 
http://www.vyncke.org/ipv6status/compare.php?metric=p&countries=us,fr,jp,de,kr

Letztere sieht die Lage vom anderen Ende her an und zählt eben auch Tunnelanten (wie Thomas und mich) mit, aber es ist tatsächlich seit Oktober ein leiser Aufwärtstrend erkennbar. Frankreich weit voraus und Südkorea als Gegenbeispiel.

Update:
Slashdot, selbst immer noch ohne ipv6, hat einen post zum Thema. Gefühltes Resumee: in Amiland kommt langsam Bewegung in die Sache, ein großer Provider, comcast, bietet native IPv6 und andere Anbieter scheinen in Vorbereitung zu sein. Wie üblich nimmt das aesthetische Argument (die neuen IPs sind so lang / schlecht durchs Telefon zu sagen / iih, Buchstaben und Doppelpunkte) und die folgende Diskussion zu dhcpv6 erheblichen Raum ein.
Interessant ist vllt, dass der Vorreiter comcast mit einem Schwerpunkt seines Geschäfts Kabelanbieter ist. Hat das etwas mit der an die Endkunden verteilten Hardware zu tun oder warum sind Kabelanbieter in dieser Hinsicht anscheinend wendiger / innovationsfreundlicher?

Ts, ich entsinne mich an Zeiten, als die technointeressierte Crowd, die sich im Internet organisierte / begegnete, scharf war auf Neuerungen, neue Versionen, erweiterte Protokolle, was nicht. Bunte Vergangenheit!

Update 2:
Telekom - IPv6-user gibt es wirklich - dieses kleine Blog hatte den ersten Besucher aus 2003:: am 15.9.2012
 

update 3:
Ich habe da ein kleines plugin fuer Piwik entdeckt, dass IPv4 vs IP6 traffic mitzaehlt. Vllt gibt es dazu bald einen eigenen Eintrag,  erste Tageswerte liegen bei 5-6% IPv6. Vorne dran scheint KabelBW, Tunneln (HE, Sixxs) und dann mal Unitymedia, mal M-Net, mal Telekom.

update 4:
Seit Mitte Januar zählt mir Piwik nun die beiden Protokolle aus und, mal den Februar im ganzen genommen, erreichen mich tatsächlich 5% der Besucher via IPv6. Auch von der Verteilung bestaetigt sich das Bild (gefühlt! ich mache immer mal einen whois auf v6er, aber ohne jeden methodischen Anspruch): Vorne dran die Kabelnetze, dicht gefolgt von den Tunnelanten und dann der Rest als Streufeld: Google, Dassault-systems, Telekom, das chin. Universitätsnetz und quasi ein Cluster von Klein- und Kleinstanbietern aus Bayern. 
Gemessen an den repräsentativen Statistiken sind 5% natürlich ungewöhnlich viel. 
 
update 5:
Die Schweiz, Rumänien, Frankreich und Letzeburg liegen inzwischen mit 10 - 5% IPV6-Nutzung vorne in der Statistik, Deutschland nähert sich sachte den 3%, mit einer auffällig stetigen Kurve. Fast möchte man sagen, verdächtig stetig - Sprünge nach oben wären bei Ereignissen wie "weiterer ISP schaltet IPV6 frei" zu erwarten, Sprünge nach unten bei Ausfällen. Beides scheint in DE nicht vorzukommen. 
Die Zahlen sind nur ca. zutreffend, denn angesichts der anhaltenden Blockade seitens der ISP haben Tunnelanten einiges Gewicht. Und da zieht Sixx Traffik-anteile nach Kerneuropa, während meine Nutzung (via HE) andererseits die Statistik der US auspolstert.
 

Google Drive for Linux

Thursday, December 27. 2012

So, Google intros a new service, Drive, and there are clients for Android, Win* and OSX. But not Linux. Many comments, requests, a blog entry with the news that Google is working on it,  "coming really soon now" - and nothing about it since then.

I didn't miss it until I was playing with some files on my android phone and the usb-connection was bitching on me again. Android offered to send the files to my Google Drive, fine, I could always install Drive in a win virtual machine. But before I did this some Google searching led me to a third party project: grive 

Just reached alpha after some weeks of fast developüment. There are binary packages available for Fedora and Debian testing 64, the latter fits my environs but I soon remove the package again, those binaries are from a very outdated version not capable of much. Current version (2012-06-16) is grive version 0.2.0.

Thus: compile it yourself. I fetch the sources as a .zip from https://github.com/Grive/grive/zipball/master and unpack it all in an empty folder.

Or do it the git way:

cd /path/to/yourGriveSourceCodeDir
git clone git://github.com/Grive/grive.git

and for updates:

cd /path/to/yourGriveSourceCodeDir
cd ./grive
git pull origin master

next I turn root to install some packages:

 

apt-get install libjson0-dev
apt-get install libcurl4-openssl-dev
apt-get install binutils-dev
apt-get install libboost-dev
apt-get install libboost-filesystem-dev

cd into the source folder and there:

mkdir build
cd build
cmake ../
make
make install

Switching back to my user account I enter  grive -a  which produces n authentication request which I copy from the console output into my browser's adress field, as a result of it I get an authentication key which I enter into the waiting prompt at my console again. Hit enter and grive creates a file ./.grive to store the key within.

The next thing is to create a folder to be my Google Drive, i.e.  ~/documents/GoogleDrive/, cd to it, enter grive in the console synchronzation starts.

Unlike the android or win* clients grive does not sync all the GoogleDocs files (.gttable, .sheet, gdoc) that may be in Google Drive nee Google Docs.And there is no grive demon watching the folder for changes and autosyncing it. Well I can always script a cron job for that.

I notice a somewhat unexpected behavior about the .grive file as grive always expects this file to be in the currently active directory (and not, as I would have expected, in ~/). This might let me set up several independant google drive syncs next to each other but it forces me to always navigate to the local Google Drive root folder before starting the sync or else grive asks for a fresh authentication. I would prefer a config at ~/.grive, possibly with a list of Googledrive folder paths and auth keys.

While grive 0.1.0 didn't sync in the upload direction (local only files were regarded as "deleted on remote" and renamed to hidden) grive 0.2.0 actually uploads them. There is a new Readme which plans a daemon mode for a future release, I worked my way around this manko using iWatch to watch for filechanges on the local side.

But all in all it's not bad for a start, certainly beats what Google has to offer ;-)

grive accepts these parameter:

  • a   authentification
  • l   log
  • v   version
  • V   verbose
  • f   force

Sync with  log goes like:
grive -l.griveLog.txt

The log confirms what I saw before: hidden files and google documents are actively ignored.

Update:
grive version 0.2.0 has a number of new options, the sources come with a updated and informative readme and it even has a man page now, so man grive will tell you what it does. 
Some usefull info is at http://www.lbreda.com/grive/installation , currently related to version 0.1.1 

Intellimouse unter Arch Linux/KDE

Saturday, December 1. 2012

 Wenn man eine Weile mit Linux, namentlich KDE unterwegs ist vergisst man teilweise wie unpraktisch manches unter win* ist. Copy&Paste zB, mit KDE habe ich da: zwei unabhaengige Zwischenablagen, markieren/mittlereMaustaste und Control-C/Control-V. Und dann habe ich noch Clipper, der still und leise im systray sitzt, nie muckst und alles in einer Liste einstellbarer Länge zum Wiederaufruf bereit hält.

Nun bin ich neuerdings arbeitsmässig doch wieder mit einem consultants-Laptop mit win7 unterwegs und da gibt es kein markieren/mittlereMaustaste. Da, wo es fehlt, merke ich erst, wie praktisch dieses Feature ist. Und Clipper gibt es natürlich auch nicht,s tattdessen installiere ich mir irgendein Clipboar-Manager, der muckt und nervt, so dass ich ihn dann doch wieder abwschiesse, wenn ich ihn nicht wirklich brauche.

Und umgekehrt: unter win stecke ich eine Maus an, muss vllt., wenn sich w7 nicht mehr daran erinnert, dass es gestern noch mit dieser Maus zurechtkam, eine Weile auf den blauen Kreisverkehr schauen: aber dann geht die Maus und alle Knöpfe auch. Unter arch dagegen kennt meine Intellimouse zwar den linken und rechten Button und übersetzt das Rollen des Scrollrades , aber den Klick darauf als mittleren Button zu verstehen (und schnell mal zu pasten) - das klappt nicht. Von den Daumen-Button ganz zu schweigen.

Das Arch-Wiki hat hilfreiche Artikel zu Xorg und Alle Mousebuttons aktivieren , nützlich fand ich  noch dies und das.
Den erkannten Namen der Maus findet
egrep "Name|Handlers" /proc/bus/input/devices

Ich habe dann in /etc/X11/xorg.conf.d eine Datei 20-intellimouse.conf angelegt mit diesem Inhalt:

 

Section "InputDevice"
         # Make sure you use the identifier specified in the
         # ServerLayout section.
         Identifier  "Evdev Mouse"
         Driver      "evdev"
         Option      "Protocol" "ExplorerPS/2"
         # Change the device to point to the correct location!
         # I use the USB connection under devfs
         Option      "Name" "Microsoft Microsoft IntelliMouse® Explorer"
         Option      "Device" "/dev/usbmouse"
         Option      "Buttons" "7"
         Option      "ZAxisMapping" "6 7"
EndSection
 
Damit wird Klick aufs Rad als MittlereMaus erkannt .
 
 

 

(Page 1 of 1, totaling 4 entries)