Archive

Archive for the ‘God Damnit Linux’ Category

KDE is a terrible tease and the reason we can’t have nice things

October 15th, 2009 5 comments

Last night I installed KDE and I was absolutely thrilled. For starters, it has built in widgets, which I absolutely love (when they work, that is). In general I find it a lot easier to customize than GNOME, and themes are easier to implement and look much nicer. This is a shot of my current desktop:

It's rather pretty

It's rather pretty

KDE also natively supports rotating wallpapers, which is absolutely wonderful – I had spent several futile hours toiling with cronjobs in GNOME desperately trying to get it to work. I’m not particularly proficient with Linux, so the fact that KDE offered this right out of the box really appealed to me.

The widgets range from useless-but-amusing (such as the Fuzzy Clock, which gives inaccurate times) to the practical-but-amusing (I have my frequently used folders in the top right corner) to the wonderful-but-broken (any weather widget). I’m actually a bit frustrated with the last one – I tried using LCD Weather Station, and it worked for the UK and the US, but it couldn’t read Environment Canada’s data. Maybe we could change our name to “United Canada” or something.

It gets a bit ugly

Being rather pleased with my progress, I turned on the computer this morning hoping to get my second monitor working. I plugged it in, started up my laptop and then ohjesusgodwhy my laptop and monitor started blinking on and off furiously, rendering my system unusable. Restarting X seemed to do the trick, and my laptop and monitor were synchronized and working properly. However, my monitor was only running at 1600×900, not its native 1920×1080. I decided to fix this in the most daring manner I could: changing the resolution to “1920×1080″. KDE, seeing through my dirty bag of tricks, had none of it and promptly started blinking and seizing, and to (probably incorrectly) quote Mike Tyson, convulsing like an infantile retard.

I had to restart xserver a few dozen times and finally got my system stable again, albeit without running the monitor. I tried the next most daring thing I could think of: going to the display settings. This enraged KDE so much that it decided to go into convulsions again. I restarted my computer hoping that would fix things. Nope, more convulsions. I tried using Catalyst, but that had no effect – literally – I couldn’t even add the new monitor. All in all, I basically tried restarting xserver/my computer a few times, and once the monitor seemed to work properly, I’d stop fiddling with it and accept my half-hearted victory.

Oh, and when I close my laptop the system assumes I’ve logged out, so I currently have the most useless dual monitor setup. Hopefully that’s easy to change.

So yeah, to hell KDE’s seduction.

Categories: God Damnit Linux, KDE, Linux Mint, Sasha D Tags:

GUI Failure

October 14th, 2009 No comments

Now that I’m running the Testing repositories, I actually get regular updates. Today, there were 15 available for my system. However, when I started the update manager, I was confronted with this dialog:

Screenshot-Upgrade-Fail

Well what the hell does that mean, anyway? Does it mean that the safe-upgrade will not remove any existing packages or install any new ones? Or is it asking if I would like to perform a safe-upgrade as opposed to installing new packages? Should I just click the Yes button, because it is green and the No button is red? Am I even seeing the correct colours? I am colourblind, you know. Furthermore, if I don’t understand what’s happening here, where can I get more information? How come, no matter what I choose, the Apply button on the next screen is disabled until I manually clear and re-select every update in the list? Lastly, how come the entire update manager crashes when I hit the Check button? It seems unable to resolve one of the sources in my list (one that doesn’t even appear in my /etc/apt/sources.list file), and instead of timing out, sits, waiting, presumably forever, no matter how many times I hit the Cancel button. I’m a seasoned computer user with well over a month of Linux under my belt and I’m concerned – what of those other users who don’t know shit about shit? I want blood, damnit!

/rant.




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Portage drops the canoe, crushing my Gentoo installation

October 13th, 2009 No comments

In the process of migrating to KDE as my desktop environment (selected as I have no experience with the newest versions, and I want an entire desktop environment as opposed to just a window manager) I decided to use the fateful eselect profile utility.

Gentoo has a system profile selector, where you can choose the Portage profile that best suits your environment and needs for the computer. My existing profile was default/linux/amd64/2008.0, and I decided to switch to default/linux/amd64/10.0/desktop. I then ran emerge –update –deep –newuse world to completely rebuild and update packages accordingly.

Bad idea.

Portage indicated that I had hundreds of dependency conflicts and refused to update or install additional packages, no doubt aggravated by my use of “autounmask” and Portato’s dependency resolver. The most visible problem was Ekiga depending on GTK+ 2.6, which depends on GNOME 2.26, which itself depends on Ekiga. It was a giant circular mess that left me unable to resolve dependencies. I tried all the traditional fixes, including depclean and trying to reset my package.keywords file.

Faced with an intermittently working desktop, I flattened and reinstalled the system last night and am continuing to get things back up in working order, this time with the QT libraries enabled. (KDE is currently compiling – I’m using twm, the default X window manager, to run a web browser.) A few things I noticed this time around:

  • Don’t necessarily put a whole ton of USE flags in your /etc/make.conf file at first. Portage is pretty good at telling you if a flag is required for a package, and you can always recompile something if you need to.
  • In the latest amd64/10.0/desktop profile, X.org comes with version 1.6. I had no end of difficulty getting an xorg.conf file created with X -configure – it would start and load with only a black screen. I ended up running X.org using startx, then using nvidia-config to generate a base file.
  • evdev (for input device support) works great, provided you have hal and dbus USE flags and the appropriate daemons are started. I didn’t even have to touch the input device section of xorg.conf.
  • Select your system profile first, before changing it will cause grief!



My last Linux Experiment posts focused on running Linux From Scratch (x86_64).
I currently run a mix of Windows, OS X and Linux systems for both work and personal use.
For Linux, I prefer Ubuntu LTS releases without Unity and still keep Windows 7 around for gaming.
Check out my profile for more information.

Where did my Desktop go?!?!

October 8th, 2009 3 comments

My desktop used to have icons… And when I right-clicked on it, a fancy little menu came up that let me do things to it. It is now missing in action – and I think I might know why.

This afternoon, I was tidying up my home folder, carelessly deleting some crap that I didn’t think I needed anymore, when I deleted a folder called file: that seemed only to contain the the directories /home/jon/Desktop. I drilled all the way down into this directory, concluded that it was empty, and deleted it. A few moments later, my desktop disappeared.

LINUX!

Edit: I restored the folder to it’s original location and restarted the machine; Everything was back to normal, but I don’t understand the significance of that directory. It doesn’t appear to contain anything, even from a root terminal.




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Blackbery Sync Attempt #3: Compiling from Source

October 5th, 2009 7 comments

After my first two attempts at getting my Blackberry to sync with Mozilla Thunderbird, I got pissed off and went right to the source of my problems. I emailed the developer of the opensync-plugin-mozilla package that (allegedly) allows Thunderbird to play nicely with OpenSync, and gave him the what for, (politely) asking what I should do. He suggested that I follow the updated installation instructions for checking out and compiling the latest version of his plugin from scratch instead of using the older, precompiled versions that are no longer supported.

I set to it, first removing all of the packages that I had installed during my last two attempts, excluding Barry, as I had already built and installed the latest version of its libraries. Everything else, including OpenSync and all of its plugins went, and I started from scratch. Luckily, the instructions were easy to follow, although they recommended that I get the latest versions of some libraries by adding Debian’s sid repositories to my sources list. This resulted in me shitting my pants later in the day, when I saw 642 available updates for my system in Synaptic. I figured out what was going on pretty quickly and disabled updates from sid, without ruining my system. If there’s one thing that Windows has taught me over the years, it is to never set a machine to auto-install updates.

Once I had the source code and dependency libraries, the install was a snap. The plugin source came with a utils directory full of easy to use scripts that automated most of the process. With everything going swimmingly, I was jarred out of my good mood by a nasty error that occurred when I ran the build-install-opensync.sh script:

CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘libopensync1;>=0.39′ found
Call Stack (most recent call first):
cmake/modules/FindOpenSync.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:15 (FIND_PACKAGE)

CMake Error at cmake/modules/FindOpenSync.cmake:46 (MESSAGE):
OpenSync cmake modules not found.  Have you installed opensync core or did
you set your PKG_CONFIG_PATH if installing in a non system directory ?
Call Stack (most recent call first):
CMakeLists.txt:15 (FIND_PACKAGE)

It turns out that the plugin requires OpenSync v0.39 or greater to be installed to work. Of course, the latest version of same in either the Debian main or lenny-backports repositories is v0.22-2. This well-aged philosophy of the Debian Stable build has irked me a couple of times now, and I fully intend to update my system to the testing repositories before the end of the month. In any case, I quickly made my way over to the OpenSync homepage to obtain a newer build of their libraries. There I found out not only that version 0.39 had just been released on September 21st, and also that it isn’t all that stable:

Releases 0.22 (and 0.2x svn branch) and before are considered stable and suitable for production. 0.3x releases introduce major architecture and API changes and are targeted for developers and testers only and may not even compile or are likely to contain severe bugs.

0.3x releases are not recommended for end users or distribution packaging.

Throwing caution to the wind, I grabbed a tarball of compilation scripts from the website, and went about my merry way gentooing it up. After a couple of minor tweaks to the setEnvOpensync.sh script, I got the cmpOpensync script to run, which checked out the latest trunk from the svn, and automatically compiled and installed it for me. By running the command msynctool –version, I found out that I now had OpenSync v0.40-snapshot installed. Relieved, I headed back to my BlueZync installation. This time around, I managed to get right up to the build-install-bluezync.sh script before encountering another horrible dependency error:

– checking for one of the modules ‘glib-2.0′
–   found glib-2.0, version 2.16.6
– Found GLib2: glib-2.0 /usr/include/glib-2.0;/usr/lib/glib-2.0/include
– Looking for include files HAVE_GLIB_GREGEX_H
– Looking for include files HAVE_GLIB_GREGEX_H – found
– checking for one of the modules ‘libxml-2.0′
–   found libxml-2.0, version 2.6.32
– checking for one of the modules ‘libopensync1′
–   found libopensync1, version 0.40-snapshot
– checking for one of the modules ‘thunderbird-xpcom;icedove-xpcom’
–   found icedove-xpcom, version 2.0.0.22
–     THUNDERBIRD_XPCOM_VERSION 2.0.0.22
–     THUNDERBIRD_VERSION_MAIN 2
–     THUNDERBIRD_XPCOM_MAIN_INCLUDE_DIR /usr/include/icedove
–     NSPR_MAIN_INCLUDE_DIR /usr/include/nspr
–     THUNDERBIRD_XPCOM_LIBRARY_DIRS /usr/lib/icedove
–     THUNDERBIRD_XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
– checking for one of the modules ‘sunbird-xpcom;iceowl-xpcom’
–   found iceowl-xpcom, version 0.8
SUNBIRD_INCLUDE_DIRS /usr/include/iceowl;/usr/include/iceowl/xpcom;/usr/include/iceowl/string;/usr/include/nspr
SEVERAL
–      SUNBIRD_MAIN_INCLUDE_DIR /usr/include/iceowl
–      SUNBIRD_VERSION 0.8
– Found xpcom (thunderbird and sunbird):
–   THUNDERBIRD_XPCOM_VERSION=[2.0.0.22]
–   SUNBIRD_VERSION=[0.8]
–   THUNDERBIRD_VERSION_MAIN=[2]
–   SUNBIRD_VERSION_MAIN=[0]
–   XPCOM_INCLUDE_DIRS /usr/include/nspr;/usr/include/icedove;/usr/include/icedove/addrbook;/usr/include/icedove/extensions;/usr/include/icedove/rdf;/usr/include/icedove/string;/usr/include/icedove/xpcom_obsolete;/usr/include/icedove/xpcom;/usr/include/icedove/xulapp;/usr/include/iceowl
–   XPCOM_LIBRARY_DIRS /usr/lib/icedove
–   XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
–   SUNBIRD_VERSION 0.8
CALENDAR_VERSION=[8]
LIBTBXPCOM_INCLUDE_DIR
XPCOM_LIBRARIES  xpcom;plds4;plc4;nspr4;pthread;dl
ENABLE_TESTING [yes]
TESTING ENABLED
– checking for one of the modules ‘check’
CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘check’ found
Call Stack (most recent call first):
cmake/modules/FindCheck.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:73 (FIND_PACKAGE)

CMAKING mozilla-sync 0.1.7
– Configuring done

From what I can gather from this output, the configuration file was checking for dependencies, and got hung up on one called “check.” Unfortunately, this gave me zero information that I could use to solve the problem. I can verify that the install failed by running msynctool –listplugins, which returns:

Available plugins:
msynctool: symbol lookup error: msynctool: undefined symbol: osync_plugin_env_num_plugins

Ah, shit. Looks like I’m stuck again. Maybe one day I’ll figure it out. Until then, if any of our readers has ever seen something like this, I could use a couple of pointers.

More XKCD

October 4th, 2009 No comments

I swear that I’ve encountered this before…

That is all.

Categories: Flash, God Damnit Linux, Hardware, Jon F, Linux Tags:

WTF #17(qq)

October 2nd, 2009 No comments

It’s no secret that Linux, as with any other operating system (and yes, I realize that I just grouped all Linux distributions into a collective) has its idiosyncrasies.  The little things that just sort of make me cock my head to the side and wonder why I’m doing this to myself, or make me want to snap my entire laptop in half.

One of these things is something Tyler previously complained about – a kernel update on Fedora 11 that just happened to tank his graphics capabilities.  Now, I might just be lucky but why in the hell would Fedora release a kernel update before compatibility for two major graphics card manufacturers wasn’t released yet?

Fortunately for Tyler, a kmod-catalyst driver was released for his ATI graphics card yesterday (today?) and he’s now rocking the latest kernel with the latest video drivers.  Unfortunately for me, some slacker has yet to update my kmod-nvidia drivers to operate properly with the latest kernel.

While this is more of a rant than anything else, it’s still a valid point.  I’ve never had trouble on a Windows-based machine wherein a major update will cause a driver to no longer function (short of an actual version incrementation – so of course, I would expect Windows XP drivers to not function in Vista, and Vista drivers to not function in Windows 7; similarly, I would not expect Fedora 11 drivers to function in Fedora 12).

<end rant>

Top 10 things I have learned since the start of this experiment

October 2nd, 2009 4 comments

In a nod to Dave’s classic top ten segment I will now share with you the top 10 things I have learned  since starting this experiment one month ago.

10: IRC is not dead

Who knew? I’m joking of course but I had no idea that so many people still actively participated in IRC chats. As for the characters who hang out in these channels… well some are very helpful and some… answer questions like this:

Tyler: Hey everyone. I’m looking for some help with Gnome’s Empathy IM client. I can’t seem to get it to connect to MSN.

Some asshat: Tyler, if I wanted a pidgin clone, I would just use pidgin

It’s this kind of ‘you’re doing it wrong because that’s not how I would do it’ attitude can be very damaging to new Linux users. There is nothing more frustrating than trying to get help and someone throwing BS like that back in your face.

9: Jokes about Linux for nerds can actually be funny

Stolen from Sasha’s post.

Admit it, you laughed too

Admit it, you laughed too

8. Buy hardware for your Linux install, not the other way around

Believe me, if you know that your hardware is going to be 100% compatible ahead of time you will have a much more enjoyable experience. At the start of this experiment Jon pointed out this useful website. Many similar sites also exist and you should really take advantage of them if you want the optimal Linux experience.

7. When it works, it’s unparalleled

Linux seems faster, more featured and less resource hogging than a comparable operating system from either Redmond or Cupertino. That is assuming it’s working correctly…

6. Linux seems to fail for random or trivial reasons

If you need proof of these just go take a look back on the last couple of posts on here. There are times when I really think Linux could be used by everyone… and then there are moments when I don’t see how anyone outside of the most hardcore computer users could ever even attempt it. A brand new user should not have to know about xorg.conf or how to edit their DNS resolver.

Mixer - buttons unchecked

5. Linux might actually have a better game selection than the Mac!

Obviously there was some jest in there but Linux really does have some gems for games out there. Best of all most of them are completely free! Then again some are free for a reason

Armagetron

Armagetron

4. A Linux distribution defines a lot of your user experience

This can be especially frustrating when the exact same hardware performs so differently. I know there are a number of technical reasons why this is the case but things seem so utterly inconsistent that a new Linux user paired with the wrong distribution might be easily turned off.

3. Just because its open source doesn’t mean it will support everything

Even though it should damn it! The best example I have for this happens to be MSN clients. Pidgin is by far my favourite as it seems to work well and even supports a plethora of useful plugins! However, unlike many other clients, it doesn’t support a lot of MSN features such as voice/video chat, reliable file transfers, and those god awful winks and nudges that have appeared in the most recent version of the official client. Is there really that good of a reason holding the Pidgin developers back from just making use of the other open source libraries that already support these features?

2. I love the terminal

I can’t believe I actually just said that but it’s true. On a Windows machine I would never touch the command line because it is awful. However on Linux I feel empowered by using the terminal. It lets me quickly perform tasks that might take a lot of mouse clicks through a cumbersome UI to otherwise perform.

And the #1 thing I have learned since the start of this experiment? Drum roll please…

1. Linux might actually be ready to replace Windows for me

But I guess in order to find out if that statement ends up being true you’ll have to keep following along ;)

Resolving the DNS Issue Once and For All

October 2nd, 2009 3 comments

A little while ago, I wrote about problems that I was having with my laptop not resolving DNS requests. After I restarted today (because X11 crashed, but that’s a whole other can of worms), it started happening again, even though I had fixed the problem once before. Turns out that the big warning banner at the top of the resolv.conf file was relevant, and that my changes were eventually lost, just not on the first reboot.

So I moved back to my Windows machine for a few minutes to hit up the #debian IRC channel, where I explained my issue and what I had done to solve it last time. Luckily, somebody there presented me with a new solution to the issue that should persist restarts. Instead of making edits directly to resolv.conf, I was instructed to add a prepend line to the /etc/dhcp3/dhclient.conf file:

#add a prepend line to fix DNS issues
prepend domain-name-servers 64.71.255.202;

Where the IP address is the IP of your DNS server (OpenDNS, in my case). After saving the file, I ran

/etc/init.d/resolvconf restart

to apply the changes and restart the DNS lookup service thinger. I know that doesn’t sound very technical, but I honestly don’t know anything about the part of the network stack in Debian is responsible for DNS lookups, aside from the fact that it may or may not be called resolvconf, so you’ll have to live with it.

In any case, this seems to have worked quite well, so check into it if you’re having problems resolving DNS addresses on your machine.

Barry: Round Two with the Blogosphere riding Shotgun

September 30th, 2009 2 comments

Given the problems that I’ve been having lately with getting my Blackberry calendar and contacts to synchronize with anything in Linux, I was quite surprised when I almost got it working tonight. Forgetting everything that I’ve learned about the process, I started over, following these helpful tutorials and working through the entire install from the beginning. Unfortunately, aside from some excellent documentation of the install process (finally), the only new idea that those blogs provided me with was to try syncing the phone with different pieces of software. Specifically, Chip recommended KDEPIM, although I opted to  jump through a few more hoops before giving in and dropping the Thunderbird/Lightning combination entirely.

After a bit more mucking about, I decided to give up Lightning and installed Iceowl, Debian’s rebranding of Mozilla Sunbird, instead. Iceowl is the standalone calendar application that Lightning is based on, and is a very lightweight solution that is supposed to cooperate with the opensync-plugin-iceowl package. In theory, this allows calendar data to be shared between my device and the Iceowl calendar after configuring the plugin to read my Iceowl calendar from the /home/username/.mozilla/iceowl/crazyfoldername/storage.sdb file. In practice, the sync process gets locked up every time:

Screenshot-PIM Synchronization - KitchenSync-1

Why must you tease me?

Well, I’ve tried everything that I can think of to get my phone to synchronize with any Mozilla product. I’m very close to giving up, which is a shame, because they really are superior products. The ridiculousness of the entire thing is that I can easily dump my PIM data to a folder, and Thunderbird stores it’s data in an SQLite database. If this were Windows, I’d have written a VB app to fix my problems hours ago… Anybody know any python?

Update: I’ve also managed to successfully synchronize my phone with the Evolution mail client. Unfortunately, Evolution looks rather pale next to Thunderbird. In fact, the entire reason that I switched to Thunderbird about a week ago is that Evolution mysteriously stopped receiving my IMAP email with no explanation. No new email comes in, and the Send/Receive button is grayed out. Until now, I was happy with my decision, as Thunderbird is a superior application.