Nuudelisoppa

Tag: glitch

  • Sonera katkaisi kilpailijankin piuhat Kiihtelysvaarassa

    Maaseudun Tulevaisuus via Juha

  • Pidgin 2.4.0: the chat input field is no longer user-resizable

    Pidgin Trac

  • Nokian älypuhelin paukahti kuin popcorn

    Kauppalehti (via I-S)

  • Insecure routing redirects YouTube to Pakistan

    ars technica

  • Local root exploit in Linux 2.6.17-24

    /. via reddit

  • WordPress and a problem with URLs containing UTF-8 characters

    Looks like WordPress does rather poorly with internationalized domain names. I just tried adding such a bookmark, and WordPress ate all the non-ascii characters. I can change the URI directly from phpMyAdmin, but WP still refuses to display or link it correctly both in the Blogroll management and on the site.

    (Sorry about the somewhat misleading title, but that’s how I went googling for the problem, so maybe someone else will, and can find a confirmation for their suspicions here.)

  • Kuluttajavirasto: digilähetysten tekstitysongelmia ei tarvitse sietää

    Kuluttajavirasto

  • Solved: Miro: purple videos / video has wrong color

    I ran into this problem once before, but back then it seemed to resolve itself simply by restarting Miro. This time I wasn’t so lucky, so I had to find another solution. It was under the Tips and tricks section on Miro developers’ site and was linked to by bdelacey over at Miro forums.

    The solution is to add a list key (of type string), /apps/miro/renderers with gconf-editor, and then add a gstrenderer item under it. Apparently what this does is use the gstreamer renderer instead of Miro’s default of xine, and since the videos are shown correctly in Totem (which also uses gstreamer) they’re now okay in Miro as well.

    The only thing I’m left wondering is how did this solution come to effect by itself the last time, as I certainly didn’t do anything with gconf back then.

  • The Gnome way, adding the second panel back and a flipped Nautilus

    I had emulated Windows’ look and feel shortly after I began using Ubuntu, but I have now became convinced of the Gnome way being the right way. I realized my brain was already confused with the location of the menus due to just the short dip into the Gnome default. That is to say, I found myself looking for the desktop menus from the top of the screen although I had only just touched that solution briefly in the beginning – what more proof is needed for the naturalness of the Gnome way? So, in an attempt to follow the Gnome philosophy to the strictest, I tried to re-organize my desktop back to the way it was right at the beginning.

    It took me some time to find out how to add the second panel back, as most of the Ubuntuforums threads seemingly related were not, so here’s how to do it: point to the other panel you have, right-click on it and select New Panel. I do wonder if the Gnome people think this is the most accessible way of doing this; at least in my mind, the panels are added onto the desktop so I would have expected the choice to add one to be available by right-clicking on the desktop. But apparently, the birth of a panel is more like the birth of an amoeba (where one becomes two) rather than the birth of life itself (where naught becomes one).

    I tried to avoid the somewhat nasty way of removing all Gnome configuration files because I did have some settings I wanted to preserve. Unfortunately, at some point I ran into Bug #153382 (or a similar one), where Nautilus makes the desktop disappear, starts hogging up the CPU and spews error messages into a logfile in the home directory. It was only due to finding the logfile that I found out what was going on in the first place, and I have to say this is one of those bugs that, although quite easy to solve with some experience (the nautilus process needs to be killed), is probably a horrible experience for a beginner running into it.

    In the end I did have to resort to logging out of Gnome and removing the configuration files before logging back in. Luckily, the issue of virtual terminals not being visible seems to have been temporary or at least not present when I needed a console, so I didn’t have to go casting rm -rf‘s blindly.

  • Solved: svn: Working copy 'wp-content/themes/default' is missing or not locked

    I ran into this problem when trying to upgrade several of my WordPress-powered blogs through Subversion. The cause was that I had replaced the default theme directory with a copy of my working theme, due to the ‘reverts to default’ bug which, by the look of things at WP’s support forum as well as my own experience, is still alive and well.

    The default theme is part of the svn repository and svn expects to find its own data on the current status of the files, but a copy of my own theme doesn’t have the data, so it complains about the missing or not locked working copy. The solution is to delete the default theme directory based on my own, then do a svn up to fetch a copy of the original default, then do a copying-over: cp -r my-working-theme/* default/

    Now the working copy of the default looks like my own, yet is seen by svn so that a svn sw http://svn.automattic.com/wordpress/tags/2.3.3/ (or whatever the new version is) is possible. Note that editing style.css is required to tell the default apart from the actual working theme. I also like to use the screenshot of the original default to make it stand out when the working theme once again gets replaced by the default.