minicom/CuteCom Nostalgie

Ich weiss, heutzutage braucht man nur noch selten ein Terminalprogramm für serielle Schnittstellen, aber manchmal eben doch 😀 .
Und so einen Fall hatte ich gerade: mein neu aufgesetzter Debian-Server bekam im Zuge einer Entrümpelungsaktion nun keinen Bildschirm und keine Tastatur mehr, und so stellte sich die Frage, wie ich da rankommen soll, falls mal das Netzwerk nicht geht oder ein Filesystemcheck beim Boot nicht ohne Benutzereingriff durchläuft.
Also mal schnell nach ‚Linux Server serial Port boot‘ gesucht und hier: Missing startup messages on console(tty1) after the boot fündig geworden.

Bevor ich das dann in der Praxis umsetzen/testen konnte, tauchte noch das Problem auf, dass mein Server, aufgebaut aus einem ausgemusterten Dell-Desktop, gar keine serielle Schnittstelle mehr hatte.
Hier wäre nun ein USB-Serial Converter als Workaround in Frage gekommen, allerdings hatte ich davon nur einen vorrätig und der sollte schon am anvisierten Client, meinem alten EEEPC 701 (der auch schon keinen Serial Port mehr hat), Verwendung finden.
Also mal in der LPC Schrottkiste gesucht und tatsächlich eine 1-Port-Serial PCI Karte gefunden.
Eingebaut und wie oben beschrieben den Server konfiguriert (/etc/default/grub angepasst …) und dann den Client genauer angeschaut.
Auf dem hatte ich schon kurz nach der Anschaffung das vom Hersteller vermurkste Xandros Linux durch Debian ersetzt, und so steht dort auch das gesamte Repository zur Verfügung.
Das Standardprogramm für serielle Kommunikation ist auch hier minicom, also kurzerhand dieses installiert, ein Nullmodem-Kabel angesteckt und los gings.
Zuerst mal ‚minicom -s‘ gestartet und die ganzen Modem-Init-Befehle deaktiviert, da es ja hier um eine Direktverbindung geht.
Port auf /dev/ttyUSB0, Baudrate auf 115200 8N1 gesetzt (genau wie am Server) und gespannt auf den Bildschirm geschaut, ob/was sich da tut.
Und siehe da: immerhin mal ein paar Hieroglyphen 😀 .
Nach den einige Jahre zurückliegenden Erfahrungen mit Serial-Port Messgeräten sollte das mit falscher Baudrate oder Start/Stopbits/Parity etc. zu tun haben.
Und genauso war es auch: Baudrate auf 9600 gesetzt und schon klappte alles, sogar ausreichend schnell (ich denke, der serial-USB Converter kann keine 115200 BPS und fällt deswegen auf den Default-Wert von 9600 zurück). weiterlesen

https everywhere

Ab sofort auch für hoernernfranzracing.de: SSL Verschlüsselung !
Aktuell wächst der Druck auf Webseitenbetreiber/Besitzer, ihre Seiten auch oder ausschliesslich über https zugänglich zu machen, siehe z.B. ssl-zertifikat-januar-2017-pflicht und nun ist es auch hier soweit 😀 , erkennbar am kleinen Schloss und am ‚https://‘ der URL:
SSL Anzeige
Um dies zu erreichen, gibt es verschiedene Möglichkeiten, die sich deutlich in den Kosten, dem Einrichtungs- Administrations- und Betriebsaufwand, aber auch in der Sicherheit, die sie z.B. für Webshopkunden bieten, unterscheiden.

Was die Sicherheit angeht, unterscheidet man grob in 3 Kategorien: weiterlesen

Kdevelop for Web Developers

Basically, this is a follow-up on my Post about Quanta/Gubed several years ago. However, as Quanta is long dead now, unfortunately, there is clearly a need for a replacement, especially one that integrates well with KDE.

And no, I’m not going to bash established IDEs like eclipse, netbeans etc. – just a simple word: I personnaly don’t like dinosaurs 😀 . So, what’s left ? Short answer: Kdevelop . This, although commonly known as superior IDE for C++ development, especially under KDE, has come a long way and through its flexible plugin-structure, it is nowadays also a feasible alternative for other tasks, including development for scripting languages like php and python. This article will focus on the php side, as this is what I’m using it for 😀 . So, lets start with the basic features.
  • Project handling: Projects can be created from inside Kdevelop, there are templates for all kinds of projects, including php. On the other hand, it is also possible to simply open an existing directory with source files – voila, thats the new project.
  • Editing: Easy enough, as Kdevelop uses Kate as its default source code editor, which is just awesome, especally with php-documentation installed (this is usually done through  standard package managers). Syntax highlighting, code folding, online help, all is there.
But, what makes up a real, full-featured IDE ? – the integration of a powerful debugger, of course. For C/C++, it is well-known that Kdevelop integrates gdb very well, with everything needed is available as binary packages for virtually every distro. Nowadays, there is, fortunately, xdebug for php – integrated with Kdevelop through a plugin. So, lets focuse on this one. These are the prerequisites:
  • kdevelop in a recent version (I’m using 4.5.1 on Kubuntu 12.04)
  • kdevelop-php (php-plugin)
  • kdevelop-php-docs (optional, recommended)
  • kdevelop-l10n (localisation, recommended)
  • kdevelop-php-l10n (localisation, recommended)
  • php5-xdebug
then, unfortunately not commonly available as binary packages:
  • kdev-xdebug
  • kdev-php-formatter (optional)
Everything mentioned in the 1st list is usually available through the package manager of most distros, I will not further explain how to get these installed, but rather outline the steps needed to get the plugins installed that have to be built from source (usually). First step is to get everything which is needed to build KDE source packages, namely git, g++, cmake, kde development librarys and so on. For most distros, a good start is usually this . Then, general advice on how to build KDE packages from source is also on KDE techbase . A short howto (slightly outdated, e.g. executescript and executebrowser are now parts of kdevelop base, no more extra install needed) for building kdev-xdebug is available on Niko Sam’s site . This is also what I used as a a starting point. But, as this howto is a bit short (not every step obvious for n00b’s 😀 ), and, as not everything went quite well (as usual 😀 ) I decided to outline here a bit more in detail what I did, what went wrong and how I got around the problems to get it to work, finally. Maybe this will also help others… So, let’s start:
  1. get the source:
    mkdir ~/kdevplugins (or any other suitable location)
    cd ~/kdevplugins
    git clone git://anongit.kde.org/kdev-xdebug
    cd kdev-xdebug
    git branch -a (this shows which branches are there, choose the correct one: 1.5 is for kdevelop 4.5.x, 1.4 for kdevelop 4.4.x)
    git checkout remotes/origin/1.5 (use correct branch here, or master for the latest and greatest)
  2. build:
    mkdir build && cd build
    cmake .. (in case cmake complains about missing dependencies, install these and start over)
    make
  3. install:
    sudo make install
    kbuildsycoca4
  4. check kdevelop plugins if kdev-xdebug is there:
  5. enjoy 😀
Ok, at least, that’s the way it is supposed to work 😉 For me, there was the problem, that although every step obove (except 5.) succeeded, I was not able to get the debugger running, see this thread in the kdevelop mailinglist. After some investigation, and thanks to the help of Niko, the xdebug plugin developer, I succeeded to get it to run, heureka. The culprit was the installed php5-fpm extension (which makes no sense, IMHO, on a desktop computer) which blocked port 9000 on localhost, which in turn is needed by xdebug. As can be seen on the list, Niko has meanwhile added a comprehensive error message in the plugin (git master) in case anyone else is affected by this problem. Conclusion: finally, the plugin works as expected, an invaluable help when developing php code that is a bit more sophisticated than just calling phpinfo() 😀 So, no need anymore for Quanta/Gubed, in this respect. And not to forget, there are meanwhile other php/web dev related kdevelop plugins, namely:
  • kdev-upload
  • kdev-php-formatter
  • kdev-css
  • kdev-xml
which are still experimental, but promise to even further qualify Kdevelop as a real replacement for good old Quanta. (From these mentioned, I’m using kdev-upload on a regular basis, and it works so far as expected, just not deleting files on the server which have been removed locally, but that’s a minor issue, IMHO). Additional note: a simple debian package (built with checkinstall, so no real dependency checks..) can be found here: kdev-xdebug_20140201-1_i386.deb – simply download and install with ’sudo dpkg –install kdev-xdebug_20140201-1_i386.deb‘. Be warned: this is only tested on Kubuntu 12.04 with kdevelop 4.5.1 installed in default locations, including mentioned php stuff !

Thoughts about KDE/trinity…

First of all, this might seem to be mostly a rant about KDE, but I think it is not (at least partly 🙂 ).
But it is, for sure, criticism, and, of course, my very personal opinion (I am not in any way a representative of any of the mentioned projects, just a user/contributor – more or less).
So, what’s going on in the KDE world ?
In short, these are the most important activities:
In 2008, KDE4 was started as the successor to KDE 3.5, with massive changes to the underlying software stack, not just porting to qt4.
First to mention, the new desktop shell: plasma, with radical changes: no more ‚Desktop‘ with Program icons, Plasmoids instead of traditional Applications, new control widgets (‚Cashew‘) and so on…
But with all these changes, and their problems (which are quite normal in the development cycle of huge projects), it was more and more obvious that many users would not want to follow the directions given by the developers anymore.
To sum it up, there is now a clear demand for a lightweight, simple Desktop, based on technology already known (qt libs), but without the mandatory need to have more or less powerful hardware, and (at least) the option to just not install/run memory/power consuming services simply to be able to run a web browser or an email client.
And, of course, there are also (few) developers who share this opinion, and thus, we can now find at least 2 projects to follow the mentioned goals:
trinity and razor-qt, both taking a different approach, however:
while trinity stands in the direct heritage of KDE 3.5, trying to keep as much of this experience alive as possible
(including the underlying qt3 framework), razor-qt follows another paradigm:
provide a clean, slim desktop based on qt4, following widely accepted standards (xdg) without all the load something like
plasma/akonadi/nepomuk etc. bring in addition.
This doesn’t include a native set of applications, however – it is up to the user to decide which ones to add (and thus, which additional dependencies/frameworks to pull in – might end up with nearly a complete KDE4 desktop installed, though 😀 ).
The stunning fact, with these projects, is that for the first time in the KDE history, there are now ‚forks‘ which
aim to users who are not satisfied with the current direction of the project.
The interesting thing, now, is how these 2 projects are perceived in the KDE(4) mainstream, especially developers.
With razor-qt, there seems to be not very much flame-wars, at least not widely visible.
As for trinity, see e.g. this:
Pro-Linux Article (german).
KDE4 developers however, seem to be rather upset, that anyone ‚dares‘ to fork what they, appearantly, have dropped back then in 2008 (when KDE4 still was far from beeing usable in any respect) as if it were some piece of radioactive plutonium or thelike.
Anyone interested in this subject may just read Martin Grässlins articles/blogs:
Freies Magazin Article (german)
the-grass-has-always-been-greener-on-the-other-side-of-the-fence
having-a-look-at-the-oldnew-desktop-environments
or also the trinity list archives:
trinity-devel.pearsoncomputing.net (threads ‚trinity coverage‘, ‚poll‘ …)
nwhere also Aaron Seigo’s statements can be found, who obviously avoids writing something on the subject in his own blogs – looks like he wants to avoid any publicity on trinity, presumably.
So, while I do not want to comment on the more technical argumentations in the cited sources, it seems to me that the KDE4 developers just can’t stand nor tolerate the fact that there are still users (and developers!) who prefer that what KDE3 offered: a fast, snappy Desktop (even on older Hardware) with a complete (though, with some respect, outdated) set of applications, without all the recently added ‚bloat‘ 😉 .
As a conclusion, simply time will tell wether trinity and/or razor-qt will survive (I personally hope so), and what direction KDE4 will go.

KDE 4.1 is out

So, now KDE 4 is nicely getting into shape – much has been improved/added since the launch of 4.0 in january.
I’m currently evaluating the 4.1 packages from kubuntu, and I must say, I’m more and more using it as my main desktop for day-to-day tasks.
There are still some rough edges, of course, as well as missing configuration options (e.g. adding favorites in kickoff menu still not possible from GUI), but as usual, these issues are getting fixed quickly.
Most important for me, however, is the significantly increased responsiveness and speed of the whole thing – still not exactly as snappy as 3.5.x, but much better than 4.0.x.
Also, more and more applications are getting ported to kde4, such as kblogger (which is what I’m using ATM to write this post 😀 ) – what I’m still missing is konversation and kdewebdev.
And, yes, there are many new things to discover/play around with – reading other blogs about these helps getting started,
often even more than just the impressive changelogs in the official announcements.
As a first conclusion, KDE 4.1 is now in shape to be adopted by a broad audience of (curious) users – I can only encourage anyone to give it a try, at least as an additional install alongside the well known 3.5.x, it is well worth doing so.

1 week with KDE 4.0 – first impressions

Now that kde 4.0 is out for one week, I’ll try to make a short summary of my experience with it:

+ installation (using kubuntu gutsy) is a breeze
+ coexists nicely with kde3.5, uses separate path (/usr/lib/kde4) as well as personal configuration (~/.kde4)
+ import preferences (e.g. konqui bookmarks) from kde3.5 is easy
+ little quirks/annoyances get fixed at astounding pace
+ kde3.5 apps run nicely within kde4
+ kickoff menu is impressive
+ system settings much better organized/cleaner than kde3.x’s control center
+ krunner is much more informative/flexible than previous ‚ALT-F2′
+ building cmake-based kde4 apps from source (e.g. from kde-apps.org) is much more convenient than the old auto* stuff (crap) weiterlesen