yoush.homelinux.org

Yes it is. Go read this.

P.S.
My own – yet very limited – experience of running android port on a custom board, only proves that. Android crashes and burns on almost any possible error. Audio driver failed to initialize? Crash. USB keyboard connected? Crash. It behaves even worse than windows 10 years ago.

Shame on google.

There are lots of wikies in the web running on MediaWiki software. Most of those are far not as large as WikiPedia, but contain only several 10s or 100s of pages.

Today I faced a situation when it would be good to download entire content of a MediaWiki installation, for futher offline browsing.

Doing so using variants of wget --mirror turned to be next to impossible, because wget ended downloading all edit- and special-links, and was unable to complete within an hour, then I interrupted it. Using --reject flag did not help because it does not stop wget from following and downloading link, it just removes the file after download.

Here is a solution that I found:

wget -k -p -r -l 1 --html-extension --reject '*=*' http://linux-raid.osdl.org/index.php/Special:Allpages

This command completed in several seconds, and produced exactly what I wanted – cross-linked copies of all wiki pages, and almost no garbage.

If there is a better method, please let me know

Unfortunately some of my work colleagues use yahoo messanger for IM needs.

This have been not a big problem for years – I just installed python yahoo transport into our local jabber server, and communication just worked.

…until today. Since today, yahoo transport no longer connects. They want newer protocol.

So basically they behave like ICQ.

Why in the world do people use this shit instead of proper IM tools?..

We are still running several servers under Xen control. That was perhaps a mistake to choose Xen, but now over 20 domU’s are there and moving to something better is hard.

Today during system maintaince, I faced that one server is unable to start any domU, with an error

Error: Device 0 (vif) could not be connected. Hotplug scripts not working

Looking the net did not give an answer – people do ask about it, but answers either don’t exist, or are clearly not my situation.

So had to search for solution myself.

At some moment I noticed that server has several udevd processes running. That looked wrong for me. I attached to one of those with strace -p and found that it is hanged in sendto() to a unix domain socked with multipathd at the other side.

Restarting multipathd restored normal server functionality.

So who could think that hanged multipathd may affect starting Xen domUs …

Why in the world your webmasters think that you should decide if your reader will read wide or narrow text pages?

Ever heard that web browser windows are resizable?

If I have my window resized narrow – and I may have that for a reason! – why in the world I’m seeng horizontal scrollbar and text is behind right window border, while half of window contains nothing than background?

If I have my window resized wide – and I may have that for a reason! – why in the world I have to look at huge empty pads at both sides while text (e.g. code examples) is not fitting in the central field, for the best having ugly horizontal scrollbar attached, but more often just garbling other text on right?

P.S.
Still searching a nice-looking non-fixed-width wordpress theme with internationalization support …

Sometimes it is useful to have local branches following all branches in a remote repository. For example, if building debian packages from git repositories fetched from git.debian.org using git-buildpackage, one normally needs master, debian and pristine-tar branches.

To update each of those, one has to run

git fetch remotename

and then for each branch run

git checkout branchname
git merge remotename/branchname

Here is a helpful script to do all that automatically. Just ensure that your working directory is clean, and run

git-update-from remotename

and you get all local branches updated (and new ones created if new branches appear on the remote server).

In the past years we have used a setup with almost everything (network services, user desktop sessions, chroot environments for different projects, etc) running on a single server. It looked somewhat cool that our Linux may handle all that.

Of course there have been all sorts of problems. Some have been easy fixable, some not. But the worse problem has always been if hardware started to misfunction. Our “server of everything” have been running on different hardware, mostly PC-style. Some hardware have been working more stable, some less – but several times during those years we have been facing situations when server crashed every several hours and we had hard times to find what is wrong.

Things changed a couple of years ago. At last our lab found a way to obtain modern server hardware. On those servers, we deployed a set of Xen-based virtual machines and distributed services among those. There have been zero hardware problems and just a few software issues over two years. No crashes. No hangs. It looked wonderful compared to what was before.

… until we decided to move the servers to a server room located in the other part of our building, to reduce noice in the lab.

After moving, reconnection and initial configuration, things first looked working. But in the night one server suddenly rebooted without any visible reason.

Next workday, other server rebooted while running a handful of user sessions. For people working on thin clients in the lab, it looked like sudden desktop hang. Because of that, first idea was that network infrastructure in the building failed (before we had all equipment nearby, now we used not-our network to connect to the servers). So we went to the person who controles it … and he pinged other our server successfully.

Next we thought that server room has power supply issues. Silly idea… everything works, expect our servers. But we decided to connect the failed server to our own UPS. It started, worked for some minutes, and rebooted again.

After two years with things working, we just could not get idea that our so-well-working setup decided to break.

And actually it was our setup that had problems. After some investigation, we found a way to reproduce the crash reliably. Problem was in the kernel, I reported it as Bug #542250. After looking into the code, I even found how to fix it, tested it on the failing server, and it stopped crashing. I’ve sent the patch to the bug report.

Bug is xen-specific, and may show only on systems with several CPUs. But it is not dom0-specific – domU’s may be also affected if they run -xen flavour of the kernel, and have more than one (virtual) CPU.

We did not face this bug before the move because dom0 on the servers worked without reboot for months, so some relatively old kernel was running (this is not very good security-wise, but since dom0’s have network interfaces in restricted network only, running older kernel is not that dangerous). Perhaps kernel that was actually running did not contain the bug.

I hope the fix this will be included in some lenny update – if not, I will have to rebuild kernel locally, both for i386 and amd64, after every kernel update.

Yesterday I’ve backported pulseaudio 0.9.15-4.1 from testing to etch. It was a cumbersome job, I had to backport things as automake, udev and hal by the way.

But the result worths that – now at last sound works again in our setup (which uses SunRays and PCs displaying VNC sessions running on application server).

Backport to etch was needed since VM running SunRay Server still uses etch, and upgrading it is even more hard. Out experience with SunRay server in the past shows that we should never touch working configuration if we have chance to. Here is one of several related stories (in russian).

Sound was broken since application server was upgraded to lenny last winter.

This was not the first attempt to backport pulseaudio since we discovered that lenny version does not work for us (it hangs and/or crashes every other minute instead). But recent 0.9.15-4 version contained a promosing changelog entry, so I decided to retry. And it worked .

Working configuration includes pulseaudio 0.9.15-4.1 on application server talking to backported pulseaudio 0.9.15-4.1~deb40.1 on SunRay sever.

Backported packages are available in etch-backports section of my repository.

And here is one more explanation why.

P.S. At MSU, we do have a EMC storage device, and do use it with in-kernel multipath drivers. It works well.

Although official announcement is not published yet, this ftpmaster’s blog entry is a clear signal that we may start our party .

We have done that once again, and now the world will enjoy even better Debian than it was before!

So congratulations to everyone involved!