My New W/C Arrived Today.

…And I paid money to have it installed, as well as to have my old one taken away. The new one is a “Ravenna 3″.

The man who installed it was a younger plumber, who struck me as being quite competent overall. But there was one aspect of his job, which did disappoint me.

The Ravenna 3 has parts inside that are mainly made out of plastic, so that they won’t oxidize over time. But like most toilets, there is a tensile component which hooks into an arm, which is rotated when the flush lever is depressed, and this tensile component lifts the flapper quickly, to start the flow of water. With the Ravenna 3, the Engineers decided to use a metal chain as this tensile component after all.

When I flushed my new toilet for the first few times, the flow did not continue until the job was done, instead ending as soon as I stopped depressing the lever.

I thought to myself that it would be unlikely, that this would be a design failure. And so I looked inside, and found out, that the chain was hooked to the arm in such a way, that there was too much free play, too much length of chain between the arm and the flapper. Therefore, the user needed to depress the lever on the outside too far, before depressing it further would start to lift the flapper. And as a consequence, the flapper would also not get lifted high enough, in order to stay ‘up’, after the user released the lever.

I was able to adjust the mechanism myself, by unhooking the clasp at the end of this chain, and then re-attaching it to the chain at a shorter distance down, before hooking the clasp back onto the hole in the plastic arm. Ideally, there should only be almost no loose distance in the chain, when the flapper is fully down, and when the external lever is fully up.

Doing this adjustment resolved the issue 100%. But the really weird question in all this is, ‘I just paid to have this installed. Why should I need to adjust it?’

And I think I know the answer to this question. The younger plumber was very efficient and skilled in installing the toilet, but also must have had a mind-set common to the computerized era. ‘I followed all the steps to install this correctly. If it still doesn’t work, it must be a design failure.’ (He never actually said this; I’m just speculating at what he might have been thinking to himself.) But it wasn’t a design failure.

I’ve heard other reports, about how younger Technicians etc., will understand how to operate machinery in principle, but will not fuss as much as the older generation did, to adjust it, or ‘to play with it until it works’. And yet there still do exist mechanical systems, which need to be fine-tuned in some way.

Also, the chain of the Ravenna 3’s internal mechanism has two segments of polymer sleeve over it, which are apparently meant to prevent it from getting tangled with the flapper too easily, which older designs did. And if, people are going to be adjusting the length at which this chain is clasped, I’d recommend turning the water supply off temporarily, just so that we don’t get very cold fingers from the constantly-running water…



Print Friendly, PDF & Email

What can be used for computers to send each other quick messages over a LAN

The situation may seem familiar to some users, that they are hosting numerous computers on their LAN, and that they’d like to send a message from one to the other. Some users who were accustomed to ‘WinPopup’ and ‘LinPopup’, have been longing for a replacement. Because WinPopup is no longer a part of Windows, and because LinPopup is no longer a part of the standard Linux repositories, their use is extremely limited. For example, even if we custom-compile LinPopup and install it to our Samba server, there is no way for an up-to-date Windows computer to send us a message, because we cannot and should not install this to Windows. And, when sending a message from a Linux machine, it will often work best to do so from the ‘smbclient’ command-line, and not even to use this old program / GUI. [:1]

Yet, If we choose to install this type of software, we would like for it to be compatible between Windows and Linux machines. Otherwise, we could just be installing any software, from any programmer, paying a subscription fee per machine, and only find that our solution does not support Linux.

And so one solution which I have gone with, is called “IP Messenger“. This software is popular in Japan, and has Windows installers. There is only one note of caution from me though: Version 3.52, which I have installed under Windows, does not allow us to disable the Autostart feature, and this behavior can seem a bit malware-like. Also, if we have this daemon running, it can prevent a Windows machine from going into standby correctly. The computer could just keep waking itself up. And so my standard behavior is to terminate this program from the Systray Icon’s Context Menu manually, after every reboot.

What some people may like about this solution, is that there are at least two working Linux versions which we can install directly from the package manager: ‘xipmsg’ and ‘iptux’ . ‘g2ipmsg‘ does not work on recent Linux versions, due to “Attempting To Unlock A Mutex Which Wasn’t Locked”.

‘xipmsg’ is a bit of a kluge, an old implementation based solely on X-server-libraries, that has few of the features which IP Messenger is supposed to have. ‘xipmsg’ will simply allow a text message to be sent and received, and that is all, while the full version will also allow for messages to be given simplistic encryption and for file attachments. ‘iptux’ has more of a full-featured GUI, and allows for these features to be used under Linux as well – assuming that the machine on the other side also has these extensions installed.

Another way in which ‘IP Messenger’ differs from ‘LinPopup’ though, is that the old solution would virtually guarantee that we can receive a message, even if we don’t have this service running, “as long as our computer is turned on”. ‘IP Messenger’ cannot offer this. We would need to have the service running, in order for messages to be received, at the time they were sent.


[Edit 1: ] If we did try to send a LinPopup message to an up-to-date Samba server, in my experience, the server will request a password authentication from the sender, even though none should be necessary. Thus, the ‘smbclient’ command-line used would need to specify an ‘-N’ parameter, in addition to the ‘-M’ parameter, the former of which suppresses the password prompt.

However, when the LinPopup v2.1.0 GUI was written in 2009, there was no awareness of this specific need on the side of the sender. Hence, LinPopup would try to invoke ‘smbclient’ without this parameter, and then some users were mystified as to why the message was not sent.

So that GUI cannot even be used to send, to a current server version.


Print Friendly, PDF & Email

It is possible to mistake a configuration file for a shell script.

One source of error which I’ve observed, was even recommended in the old ‘linpopup’ package documentation.

ICYMI, “Linpopup” was a Linux extension to the Samba server, meant to allow messages to be passed directly from one computer to another on a LAN. It was based on the old “WinPopup” feature, which Microsoft discontinued with Windows XP (Service Pack 2 ? )

I think that one of the problems with the original WinPopup was, that its messages were allowed to be rich text, including URLs, which users were tricked into clicking on, because users did not recognize that pop-up windows they were getting, were in fact intended as a feature, but that these messages were eventually sent out to blocks of IP addresses as a form of spam, sometimes carrying a payload of malware.

Unlike its Windows predecessor, LinPopup only allows Plain Old Text to be sent. But this posting is not meant to describe this, as a feature of Samba. I’m intending to showcase this as an example of a type of mistake, which modern-day thinkers make when creating configuration files. In order to ready a Samba server to receive these messages, a Linux user is given the suggestion to put the following into their /etc/samba/smb.conf, near the end of their [global] section:

message command = /usr/local/bin/LinPopUp "%f" "%m" %s; rm %s

I know this, because I custom-compiled the old package, and this was stated in the documentation.

Now, it is possible to configure some other program to receive the message, which Samba leaves in the temporary file ‘%s’, as long as we remember that any message command which Samba runs, will be run as user ‘nobody’, with the privileges of user ‘nobody’. That’s not a problem. But there is a problem with this configuration line, which users ran in to, and which users had trouble pinpointing.

This is meant for a configuration file, but the above syntax would be suitable for a shell script. A configuration file will often allow for an executable program to be specified, and will even go so far as to allow command-line parameters to be passed in. But a configuration file will not go so far, as to allow two programs to be executed in sequence. That is a luxury which too many modern coders take for granted, apparently.

The two programs referred to above are



In fact, this configuration mistake will pass in the semicolon, as part of the parameters to /usr/local/bin/LinPopUp , thereby mangling the ability of this program to identify the file the message is in. And then it will pass in the string “rm” as well…

What I had to do myself, was something like

message command = bash -c '/usr/local/bin/linpopup "%f" "%m" %s ; rm %s' &

The one program I’m telling Samba to run, is ‘bash’. It, in turn, can run several other programs synchronously, asynchronously, etc..

Also, it should be noted that the ‘&’ at the end of my line, is not equivalent to its use in shell scripts, where it tells a running instance of ‘bash’, to disconnect the child process immediately, and to continue running the rest of the script. My ‘&’ does not assume that ‘bash’ is already running, and appears as a parameter to ‘bash’ itself.

For all I know, ‘bash’ could simply ignore this. But I do know, that this ‘&’ does not interfere in my message command working…


(Edit : ) And, It is up to the way the Samba server parses its configuration file, whether it expands the variables, which begin with ‘%’ , inside single quotes. It doesn’t matter that ‘bash’ would not do so.


Print Friendly, PDF & Email

Possible Solution to ‘Dropbox Missing Systray Icon’ under KDE

Just yesterday I installed the proprietary version of “Dropbox” on my ‘Debian / Jessie’ computer named ‘Phoenix’. I had the extra HD space to spare, and also had an existing Dropbox account to link to. But what I soon noticed, was the fact that I was suffering from the same problem many other users of ‘KDE 4′ were having with the newest Dropbox for Linux.

It seems that the Linux versions of Dropbox are tuned to work best under ‘Ubuntu’, not ‘Debian’. And in General, Ubuntu uses either ‘GNOME’ or ‘Unity’ as its desktop manager, which leaves many KDE users having to use the official Command Line Interface for Dropbox.

Mind you, this CLI is not bad as those go, but missing the System Tray Icon was annoying me. I had to install ‘libappindicator…’ as well as ‘python-appindicator’ from the package manager, and even after having done that, and after having restarted Dropbox using the CLI, the systray icon did not appear for me, because in recent Dropbox versions, only the ‘Nautilus’ support is included. Nautilus is the Ubuntu / GNOME counterpart, for what ‘Dolphin’ does under KDE. Luckily, there is an open-source Dolphin plugins package named


But that package assumes we already have Dropbox installed, and does not affect the system tray.

Further, I was disappointed by the fact that most of the other complaints I could Google involved KDE 5, while I needed to solve this problem with KDE 4.

And so after doing some more reading, I wrote the following script:

(Edit 03/31/2016 : ) I would like to thank Darwin Silva, who suggested a solution below, which works better for me, than the solution which I had first posted. Specifically, the solution by Mr. Silva allows Dropbox to animate the icon correctly, to show its status. I apologize for taking so long to test Mr. Silva’s solution, but often have limited time to go after all the things I should be doing on my own computers:


# "Restart"

# Allow Dropbox 3.14.7 to show a system-tray icon.
# Works under KDE 4.14...
# Only drawback: Icon has generic page as image.
# Systray Icon Context Menu fully functional.


dropbox stop

sleep 30

dbus-launch dropbox start

This seems to have done the trick for me. But be warned: This will serve us at best, Until the Next Reboot. Possibly, this script may need to be run more often. There is a workaround which fully automates that problem, but that workaround was not worth my while.

It may be possible to edit


But doing so is pointless, because Dropbox will overwrite that file, every time it updates itself…



Print Friendly, PDF & Email