I’m very fond of audacious player (audacious2 to be precise) – light-weight, fast, and follows the WinAmp (2) path. Neat 🙂
Few days ago I’ve got the following error message on audacious start-up:
** (audacious2:2348): CRITICAL **: playlist_entry_get_filename: assertion `entry != NULL' failed Segmentation fault
Reinstallation and re-configuration didn’t help; but the fix is quite trivial:
- Start the audacious as root: $ sudo audacious2 ; this should work just fine, unlike when starting as normal user.
- Add anything to the playlist, just so it’s not empty.
- Close the player.
- Now start the player as normal user; all should work now.
That’s it. Hope this helps!
To turn your box into a dev web server is pretty simple, yet I’ve seen people struggling with this over and over again, so here’s a simple TODO list.
I won’t go over the likes of Apache installation, VirtualHost setup, .htaccess settings, etc. as you can find these online very easily, and might be specific to the needs of your project.
Most of the time I see people using localhost:8080 and a myriad of other ports to work on several sites locally; but you might as well work on http://www.myproject.com locally in just 2 simple steps:
- Create a VirtualHost in Apache which goes by “the name” http://www.myproject.com, by including the following within the definition:
<VirtualHost *:80> ServerName www.myproject.com DocumentRoot /var/www/myproject/ # all the other options and definitions ... </VirtualHost>
- “Register” the domain name locally – simply add the following line to your /etc/hosts file (on Windows, this file is typically located under [Windows]/System32/Drivers/etc):
Now enable the VHost in Apache, restart Apache, and open http://www.myproject.com in the browser, and you’re ready to code off!
Note: The VHost name need not be a valid domain name – feel free to use myproject as ServerName and in /etc/hosts; just beware that some browsers will try to search for “myproject” instead of opening the local site. In such case, type in the whole http://myproject.
So, you’ve got your shiny new certificate, and your good old server. You’ve installed the certificate, chain or intermediate certificate, and all is nice and clean in FireFox, Chrome, Chromium, etc.
Then, your boss opens up his IE, and gets Certificate Error – “not issued by trusted certificate authority” and/or “issued for a different website’s address”. Of course, that’s a major pain, as IE – however bad, buggy and crappy it is – still holds majority of browsers market, as most computer users are incapable of installing a better browser.
I encountered this today, and it took me some time to figure out what’s going on, as the behavior was so strange it shut off my reasoning.
You’ve got a hosting, neat… a shared one. Now it’d be cool if you could move your subversion repositories there also. But, you can’t just daemonize svnserve or enable webdav in Apache.
SSH is the solution for you. SVN+SSH to be precise. The setup and configuration is pretty straight-forward, but there are quite a few glitches along the way.
All you’ll need for this is SSH access to the server and basic experience with the shell.
Hope this guide will help you: Setup a SVN Server on a Shared Hosting – it took me some time to get over all problems, I hope it’ll save some time to you!
Quite annoyingly, I was unable to disable touchpad on laptop through the dedicated fn combination. Bit of googling brought results fast, here’s a simple script I use now for switching on and off.
After years of using VMWare, I suddenly had to migrate to VirtualBox; I’ve been using VirtualBox for quite some time now, but not in the way I use VMWare.
First I thought it will be a short-lived trip, but now I’m happily stuck. I still had the image of VBox the way it was in the version 1.x in the head. What a blow it was to fully explore 4.x, in my case 4.0.6!
I always forget this, thought it’s trivial.
To change the program you use for diff-ing, for editing of the commit logs, and much more, edit the ~/.subversion/config file, e.g.
editor-cmd = vim diff-cmd = meld
The file is well commented, so you should find your way around it easily.
Note: with update to Ubuntu 11.04, meld stopped to work as an SVN diff program for me (seems like support for ‘-v’ parameter has been dropped); this can be solved easily – just create a new script, e.g. /usr/bin/svnmeld containing:
#!/bin/bash meld "$6" "$7"
then chmod it as executable, and use diff-cmd = svnmeld in your SVN config file.
The setup is pretty trivial, but configuration has few glitches.