Elrondelrond@identi.ca

PHP as login shell?

I am just talking to a friend. We are currently discussing powershell. And yes, powershell is somewhere between a normal shell and a programming language. But it doesn't do either really good. It's already better than cmd.exe, but well, that's about it.

And I said: "I am not using php as my login shell". My friend commented something on the lines of: "If you do that, all of your other problems on your system are probably irrelevant"

xfce4-session finally made it

All of this is really the typical fight: A user, who knows what he wants, but software thinks, that it knows better. In this case mostly theming. Yes, it's good for most users if all programs use the same theme and stuff, that helps a lot. You don't have to learn everything again. But really, some of my programs have their own theme and stuff. And then it isn't helpful if things like lxsessions's internal xsettingsd try to force every program to the same theme.

Yes, I found how to disable things. But it wasn't fun, really. You have to edit xml configs in ~/.config and stuff. But yes, it works out. So that's the good news: In free software, there usualy is a way to fix it. But having to do it at every upgrade isn't really nice.

So this time: My only problem left with xfce4-session was, that it started xfsettingsd. So I chmod a-x /usr/bin/xfsettingsd, restarted xfce4-session (luckily started from xterm, so no need to restart the X-server) and got some errors telling me the source of the start. In this case /etc/xdg/autostart/xfsettingsd.desktop. Which one can override in ~/.config/autostart/. So after doing that, everything's fine now.

Next: Filing a bug on xfce4-session to only Recommends: xfsettingsd instead of Depends:.

lxsession, xfce4-session or xterm?

I was using a stripped down lxsession to get my basic X Session going on my main devel workstation. Then I decided to upgrade to Debian-8. And what? Yeah. Things break, as usual.

My session is not simple, it has grown for like 15 years or so. Here are some bare details:

roxterm with monofur is my main terminal

pidgin for xmpp, with its own gtkrc!

xfce4-panel

xfwm4 as the wm

So I was able to pinpoint one issue to the new builtin xsettingsd in lxsession. It wants to force a theme on everything. Except: I don't want that. My pidgin has a handcrated gtkrc! Finally found how to disable that. Okay, Now that looks better.

But xfce4-panel did have a different menu. I was not able to find out, what is happening there, at least not easily.

So I thought: Drop lxsession, let's try xfce4-session. I use their WM and Panel anyway, maybe the session thing is okay. After fiddling with the xml config file and setting up my session, most things looked better. Except: I was not able to get rid of xfxsettingsd. I wasn't able to easily find out, where it got started. In my next debugging session, I'm going to use process accounting to find out, where it gets started from.

So what am I doing currently? Right, No lxsession, no xfce4-session. What then? xterm. Yeah, currently my complete X-Session is tied to a small xterm. If I close it, the session is gone. It feels like 1998 or so. Let's see, if I get that debugged in the next time.

Old Gtk2 classic theme for Grk3

I just like the old default Gtk2 theme. Yes, it's not nice and bright and what not. But I am used to it. So I wonder, wether I can get it for Gtk3? My search engine did not help, or it does not like me…

Cyanogenmod and its (visually impaired) users

A few weeks ago, I got myself a Galaxy S2 and tried Cyanogenmod on it. Here are some of my impressions.

Why the S2?

Simple: It's listed first after the GTA04 on replicant's support list. If replicant supports it, it can't be too wrong. Second it's quite cheap on your-favorite-auction-site. And finally, it's not too far away from my company's S4. And I really consider a custom ROM for my company's phone (knox is another topic).

I could have decided for the GTA04, since I have a GTA01bv03, but really, I wanted a cheap thing to toy around.

Installing CM

Let's go and install CM. The wiki explains on how to get heimdall (I backported the one in debian/testing) and then replacing the recovery with CWM. It worked mostly flawlessly. Except "adb sideload" did not work for me. I have no idea, why. So I mounted the internal usb storage and "adb push"ed the .zip onto the device. That's about it.

General usage / First impressions

Well, the first impression was mostly what I wanted:

A rooted phone

No google apps

No nonsense

Can install CACert into the system, yeah!

I was quite positively surprised by the permission restriction system. It's not uber great, but it does a good job.

Finding bugs

Really, as usual. It doesn't take me a few days (usually hours!) to find some bugs in a default install of something. So let's see.

I use tripple-tap to zoom into certain areas of the screen, if I have to. This works very good on the S4 with the verndor's 4.2 firmware. On the S2 with CM11-M11 this seems to work at first. But after doing it so many times (I have not counted it, I have no idea, why/what side effects are relevant), it freezes the screen, no taping, nothing works. "adb reboot" is usually my way out. I haven't yet reported this one, because I have no good way to reproduce it yet.

I don't have a SIM for that phone yet. So I use the thing in airplane-mode. Guess what: In airplane-mode you can't add contacts. It's a known bug. I have no idea, if someone works on it. davdroid lists it as a third party bug.

Trebuchet crashes when setting a higher dpi. The S2 has a default dpi of 240. One can use "wm density NNN" to dynamically set a new dpi and change the virtual screen size that way (the number of pixels is the same, but the screen size must be different, if the dpi is different). This is a common tool to test UIs on different sized devices. I wanted to use it to enlarge fonts/icons/everything, so it's easier to read for me. Well, Trebuchet (the default launcher) crashes when doing so. My bug report findings are listed below.

I probably have found other ones, but can't remember them now.

Reporting Bugs with CM

CM only allows bugs for snapshots. This is a development decision. Most of "my" (where I contribute and/or maintain) projects have a rule of "current master has to be stable. File bugs if it is not." For a super large project like CM other ways might be more useful. Fine.

I wanted to report problem #3 from above. So I upgraded to the latest snapshot (M12), reproduced the bug, created a proper logcat with the relevant data and filed the bug. It's CYAN-5899, if you're interested.

So what happened? It was closed within a few hours as "invalid". Yes, you're reading correctly, "invalid". Why? "CM doesn't support DPIs other than what we set by default." I really don't understand that.

This is a nice crash, easy to reproduce, really, something a developer loves! (I know, about what I am talking: I needed days to track down heisenbugs in Samba-TNG–my findings were later ported to Samba classic). So why not go ahead and fix it? Or even look at it for five minutes? If the five minutes have a result of "Well, it's easy to reproduce, but it will take us two weeks of full work time to fix. And well, ${Priorities}" would have been a fine answer. Not to mention that fixing a bug in some not-common situation usually makes things more stable, because one has to make the code better!

"wm density" is a standard developer tool. So what this says: CM does not support standard developers. I don't know, what else to write on this item…

People might want to use Trebuchet on other devices, for thatever reason. So those people are not supported either, probably. (Haven't yet tried running it on another device with increased dpi and filing a bug). But really, I doubt the bug would get better treatment.

Visually impaired people (like myself) really like to play with the dpi settings, etc. And we can happily live with broken layouts (I guess, 5 out of 10 webpages are broken for me). But a crash is just that, a crash. So one could rephrase the statement from above to "CM does not support visually impaired people".

A friend has read the bug report and rephrased the bug's closing statement to "CM doesn´t care about its users".

What next?

I haven't yet found a suitable (supported!) alternative launcher. I am considering to try Launcher3 from f-droid, maybe that one does not crash. I haven't yet checked, if it has any support or not.

I am also considering other ROMs. I haven't yet made up my mind on which ones to try next.

Chacha20-Poly1305 for TLS expires today

There is a draft rfc for using Chacha20-Poly1305 as an alternative cipher for TLS. Generally it is a good idea to have some alternative ciphers available. So it would be nice to get something like this into TLS sooner than later. AFAIK this draft rfc is only implemented by chrome and google. Of course, I'm not a cryptographer, so I don't know, if this is really as good as it looks.

Sadly, it is expiring today.

Why mrtg?

Yesterday I talked about mrtg breaking. Today, I want to explain, why I am using mrtg for logging on my homeserver.

So what are the alternatives?

munin is mrtg a little extended. I actually liked it and always intended to migrate some of my logging systems to it. But never got to it. One really nice feature is multi node/networked logging. If you have multiple boxes and want logging in a central place, munin might be an option. But that's about it. I don't really see, what I would win by switching to munin.

collectd is really a fancy upgrade. It's very efficient. So efficient, that they run the loggers every 10 s instead of every 5 min. We run collectd on one server, where we log a lot and like the resolution. It also has the networking option. If you want something advanced, go, look at it.

So why am I still using mrtg on my box?

I'm lazy, really.

I even run mrtg the old style, without rrd. Because I like to remove broken data from my graphs. Doing that on the fly with rrd is no fun. But doing it in text files is easy, really.

There are like two dozen web frontends for it. Half of them use php (I don't want php on my box, really). The next bunch is outdated or are generic rrd frontends. Which leaves us basicly with:

collection. This one is included with collectd. It works. It needs some quirks, but it works. We actually use this one on one box.

collectd-web: I just stumbled again over it and am considering to reinvestigate it.

graphite: That's the highend answer. From the quick review, this one takes a long time to setup. So that's not an option. I want someting quick and easy.

cosmic rays on my homeserver or mrtg segfaulting

Last Saturday #mrtg (why mrtg? That's a topic for another post) started to #segfault.

It was very reproducible. Running with --debug=THINGs showed, that it crashed after reading the config file. I had assumed, that it was due to some corrupt data files. Because at the same time I had some issues with some of the data sources. Running gdb on perl (mrtg is written in perl), did not seem like a good idea at all.

Today I rebooted my machine, because I wanted to switch to 3.13 from debian/stable/backports. And funnily enough, mrtg just worked again. My first thought was "Is this windows, eh?", second though was "Hmm, I don't know about any runtime crap, that I did not clean up during reproducing the segfault". And finally ended up with "Okay, it's like windows, and I don't understand it".

In the evening @joar told me about cosmic rays. It did not occur to me to run debsums on my box, or clear the cache. I should have done it. Full Stop.