Archive for 'GNU/Linux'
If Plasma dies, here’s what to do
Posted on January 11, 2010, under GNU/Linux.
Every now and then, the Plasma desktop in KDE 4 crashes on me. Usually, it restarts itself. Sometimes, it doesn’t.
If you’re cursed with the latter scenario, there’s an easy solution.
Note: As avocadohead kindly mentioned in the comments, KDE >= 4.3 has renamed “plasma” to “plasma-desktop”. So if you’re using KDE 4.3 or later, replace “plasma” with “plasma-desktop” in the commands below.
By default, KDE sets the keyboard shortcut for “Run Command” to ALT+F2. So hit ALT+F2, and type this, and hit enter:
kbuildsycoca4 && kquitapp plasma && kstart plasma
Plasma should pop back to life.
That command is actually three commands:
- kbuildsycoca4 rebuilds KDE’s system configuration cache.
- kquitapp plasma ensures that Plasma’s no longer running, instead of just, say, hung.
- kstart plasma starts Plasma.
It took me a while to figure this out. Thanks to this post, I learned about kstart. From what I’ve read, it seems that running kquitapp plasma and kstart plasma from the CLI works for some people. Unfortunately, they fail for me on the CLI:
[nickh@chameleon ~] kquitapp plasma <unknown program name>(7282)/: "Application plasma could not be found using service org.kde.plasma and path /MainApplication." [nickh@chameleon ~] [nickh@chameleon ~] kstart plasma Qt: Session management error: Could not open network socket kstart(7394) main: Omitting both --window and --windowclass arguments is not recommended [nickh@chameleon ~] <unknown program name>(7397)/ checkComposite: Plasma has an argb visual 0x9ca7300 71303169 <unknown program name>(7397)/ checkComposite: Plasma can use COMPOSITE for effects on 0x9ca6c18 plasma(7398): KUniqueApplication: Cannot find the D-Bus session server plasma(7397): KUniqueApplication: Pipe closed unexpectedly. [nickh@chameleon ~]
Matching Printable Characters
Posted on November 30, 2009, under Coding, GNU/Linux, Uncategorized.
Who doesn’t love regular expressions? They’re fucking awesome. I use’em at least 10 times per day.
Sometimes, there’re restrictions on what patterns you can use. I wanted to change a regex for validating passwords. Originally, it allowed letters, numbers, and a seemingly random collection of special characters. How lame is this?:
^[A-Za-z0-9]{1}[A-Za-z0-9_\\.\\!\@\#\-]{0,255}$
Not only are the allowed special characters arbitrary, but they’re escaping characters in a character class, and using “{1}”.
I tried changing the regex to this:
^[[:print:]]{0,255}$
Unfortunately, that wasn’t considered “valid” by the system in question. Luckily, there’s a fairly concise alternative:
^[\x20-\x7E]{0,255}$
If you find a system that lacks support for POSIX character classes, check out this Wikipedia article.
Displaying Your ViM Colour Scheme
I posted this mostly because I’m always forgetting it, and also because it’s a pain in the ass to search for on Google. I usually try “:echo g:colorscheme”, which fails miserably.
If you’re playing around with colour schemes in ViM and want to figure out which one is being used at the moment, simply type:
:echo g:colors_name
When Gnome and Firefox Are Dead Slow
I’ve had Ubuntu Karmic Koala installed on my MacBook Pro Core2Duo for 2-3 weeks now. Almost everything’s been working perfectly. However, whenever I’d start a second Gnome session and run Firefox, the machine would slow to a crawl, and X’s CPU usage would skyrocket..we’re talking >80% here.
I scoured Google for all sorts of things:
- Gnome second session is slow
- Gnome X is slow
- Gnome Xorg is slow
- Gnome Firefox slow
- X second session is slow
- Etc.
I found several other reports of this, but no solutions.
Eventually, I stumbled upon this blog post, which purports to have solved the problem. I gave it a shot, and holy shit, it worked!
Just to be verbose, here’s what I did:
- Open /etc/X11/xorg.conf .
- Add this line to the “Device” section:
Option "AccelMethod" "XAA"
So my “Device” section now looks like this:
Section "Device" Identifier "Configured Video Device" Option "AccelMethod" "XAA" EndSection
- Save the file and log-out of Gnome.
- Switch to tty1 by hitting CTRL+ALT+F1 .
- Restart GDM:
$ sudo /etc/init.d/gdm restart
Copying Between GNU Screen buffers
GNU Screen is one of those tools that makes you think “How the %&@# did I live without this for so long?!” If you work on command lines regularly, GNU Screen is a must.
In my desktop environment, I run Konsole and Yakuake, with a different Screen session in each[1]. A few days ago, I noticed that I was using the mouse to copy text between these Screen sessions. How inefficient is that?
It turns out that there’s a really easy way to copy text between different Screen sessions.
Note: I use CTRL-J as my escape command.
Copy some text to the first Screen’s buffer, and type ^J:writebuf . Now switch to your other Screen session, and type ^J:readbuf . Your second Screen session has just grabbed what you copied in your first Screen session. Paste it wherever you want, and Bob’s your uncle.
[1] These Screen sessions are different on purpose. My Yakuake session is for “throw-away” tasks that don’t necessarily pertain to any tasks that I’m currently working on.
Linux Mint Is Weird
I have a MacBook Pro. I bought it back in 2007 when I was living in Australia. It’s awesome. I love it, especially the keyboard. Unfortunately, Mac OS X has pissed me off way too many times. So I jumped ship to Linux Mint 7.
Out of the box, Mint 7 supports my Mac’s Atheros wifi card and ATI video card. That’s something that not even Ubuntu managed to do. Needless to say, I was impressed.
After installing and configuring most of Mint 7, things were looking pretty good. As some of you know, I customize KDE heavily. Shortcuts, panels, virtual desktops, colour schemes, etc. Once all of that’s configured as I like it, I don’t touch’em: they’re perfect (for me).
Mint 7 ships with KDE 4 though, which uses Plasma. Trying to get Plasma configured just right is like trying to fine-tune a space ship: it sounds like fun, but it just Ain’t Gonna Happen (tm).
While trying to configure Plasma, I ran sudo aptitude safe-upgrade, and went to bed. I awoke to hell. Well, desktop hell. None of my panels were showing, the Plasma “cashew” was missing, and right-clicking on the desktop did nothing. Fark!
To make a long story short, Steely in #LinuxMint.com on irc.spotchat.org saved me. He corrected my sources.list , and after running mintupdate, life was peachy!
Apparently, one is not supposed to use aptitude’s safe-upgrade tool, because it’ll install packages that Linux Mint doesn’t want you to.
How/why/what/?!?
<steely> mint will fix packages or omit items until they get what they consider a stable base <steely> mint uses updates levels 1 to 5 and mintupdate is set to use levels 1 to 3 by default, 4 and 5 has kernel and driver and other package updates <steely> if you use mintupdate you will rarely have problems but if you use the terminal it ignores levels and can introduce packages that conflict with mint's patches / fixes
So there you have it. When running Linux Mint, use mintUpdate, not aptitude, to perform upgrades.
In case anyone else is plagued by this problem, the solution is to comment out this line in /etc/apt/sources.list :
deb http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu jaunty main
and uncomment this line:
deb http://archive.ubuntu.com/ubuntu/ jaunty-backports main restricted universe multiverse
Next, use mintUpdate to upgrade the rest of your packages, reboot, and pray to whichever god(s) you believe in.
Idiosynchracy With Apache Rewrites
Did you know that it’s not possible to apply an Apache rewrite condition to multiple rewrite rules? I thought this would work, but requests from every IP address were being redirected:
RewriteCond %{REMOTE_ADDR} ^10\.0\.10\.10$
RewriteRule ^uploads/(.*)$ /wp-content/uploads/$1
RewriteRule (.*) http://deadorange.com/blog$1 [L,R=301]
It turns out that RewriteCond directives only apply to the following RewriteRule. So my rewrite directives above were equivalent to “If the request came from 10.0.10.10, rewrite /uploads/.* to /wp-content/uploads/.* .Next, redirect everyone to http://deadorange.com/blog$1 .”
Unfortunately, the only solution is to repeat the condition:
RewriteCond %{REMOTE_ADDR} ^10\.0\.10\.10$
RewriteRule ^uploads/(.*)$ /wp-content/uploads/$1
RewriteCond %{REMOTE_ADDR} ^10\.0\.10\.10$
RewriteRule (.*) http://deadorange.com/blog$1 [L,R=301]
That isn’t very DRY, but if it’s the only way, we have to live with it!
Importing large WordPress blogs
I just finished importing a WordPress blog with >1500 posts into a different WordPress blog. Importing the posts succeeded, but the last few steps at the end failed, like recalculating how many posts are in each category. This happened because the page always timed out; the import took more than 10 minutes.
If you find yourself with this problem, the fix is easy:
- First, comment out the following line in wp-admin/import/wordpress.php . In WordPress 2.8.4, it’s line 367.
set_time_limit( 60 );
- Configure your web server to allow PHP scripts to execute for a long time. In Apache, you do that with the “Timeout” directive:
Timeout 6000
This can be put within a specific virtual host, or configured globally.
- Increase PHP’s max execution time. This is done with the “max_execution_time” setting in the appropriate php.ini :
max_execution_time = 600 ; Maximum execution time of each script, in seconds
or within your web server’s configuration, if that’s allowed. For example, within Apache, you include this globally, or within a virtual host:
<IfModule mod_php5.c> php_value max_execution_time 6000</IfModule>
Ruby in Etch
As some of you may know, Ruby and Debian’s ways of packaging software go together like Darwin and religious zealots…as in, they don’t. So how should you install Ruby when using Debian Stable? How do you stay up-to-date with new versions of Ruby and gems?
By using Backports, and not worrying so much.
First, setup your box to be able to install backports of packages. Next, uninstall any Ruby-related packages. Yeah, that’s right. Do you know why? Because, if you’re running Etch, you’re using Ruby 1.8.5! Egad! That’s almost medieval. Make sure to uninstall irb and rdoc, too.
Now it’s time to install shinier versions…1.8.7, to be exact:
$ sudo aptitude install -t etch-backports libruby1.8 ruby1.8 rdoc1.8 irb1.8
All of that should be on one line.
There you have it. Now you’ve got Ruby 1.8.7 on Debian Stable (AKA “Etch”). Ruby’s not complete without RubyGems, though. Download the latest version to /usr/src/ , and extract it:
$ cd /usr/src/$ wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz$ tar zxf rubygems-1.3.1.tgz
Then run the setup utility:
$ cd rubygems-1.3.1/$ sudo ruby setup.rb
Let’s do one last thing to make life easier. The RubyGems setup script installed the “gem” command as /usr/bin/gem1.8 . I don’t want to have to type that “1.8″ every time.
$ cd /usr/local/bin/$ sudo ln -v -s /usr/bin/gem1.8 gem
There. Now we can run “gem” like the rest of the world.
Easy? Yar.