How I learned to let go and love Gnome 3 (sorta)

When Gnome 3 first came out, I had some problems with it. I think everyone did. It was a radical departure, to be sure.

My biggest problems, as I recall, were:

  1. Someone made the laughable decision to consider multiple monitors as one workspace accompanied by a fixed screen (or multiple fixed screens with 3+ monitors). Meaning, if I switched to a different workspace, only the view on one monitor changed. For someone who likes to maximize real estate during development, this was utterly unworkable. There was some hue and cry about this, and eventually (in the last few months) this seems to have become a proper configuration option – it still defaults to this behavior but you can change workspaces to include all monitors with the gnome-tweak-tool. At the time, the only workaround was an unsupported option, which probably contributed to 2.
  2. On the particular machine where I was trying Gnome 3 on Fedora 16, it was completely unstable. The desktop would randomly freeze every day or so without any pattern to the problem that I could discern.

I tried Fedora 17 when it came out. Some things had settled down, but there were still some stumbling blocks. I actually switched to XFCE for a while as that seem to fit my habits better. But I missed some of the razzle-dazzle, particularly the gnome-shell overlay way of finding and starting apps – old-school menus seemed so clunky after Gnome 3.

Two hurdles kept me from returning to Gnome 3 for a while.

Continue reading

Upgrades – as much fun as a barrel of rotten fish

Having neglected my aging personal desktop for some time, I decided it was time to do some upgrades and make it into something I’d enjoy developing on again. Not that I’ve made much time for that lately, but that’s just the point, you know?

First order of business: get dual monitors working again on Linux. My desktop has added PCI video boards to add to the onboard video. I’ve had as many as three monitors hooked in that way, but decided in the end that’s too much. Two is perfect. But the PCI boards aren’t initialized until quite late in the boot process. This worked fine until Fedora 9, at which point some major X11 change was made and this configuration would simply crash no matter what I did. I didn’t have the time to debug it. Staying working on Fedora 8 got less appealing as time wore on, and sadly, I mostly left it on the Windows boot (which of coruse has no problem using both monitors) to just browse the web.

Solution: get a fancy PCIe dual-head video card and just use that. Actually, getting this to work required me to do a little digging in the BIOS. There are a number of settings for what to initialize first (onboard, PCI, or PCIe), and had I poked at it enough, I might conceivably have gotten the PCI boards working. Or maybe I tried that before to no avail, don’t remember. Anyway, by initializing the PCIe board first at boot, I have dual monitors under Fedora 17.

Yes, 17! Well, it’s not technically released until Tuesday, but it’s close enough.

Next problem: adding more RAM. After reviewing what my motherboard can handle, I added two 4GB DDR2 modules to bring my RAM up to 10 GB. That part was easy. I’m gonna need that RAM, because I’m all about emulation (Android) and virtualization (VMs!) these days.

Installing Fedora 17 was a little tricky. This computer has seemingly random boot issues. For one thing, it has always refused to boot from USB. That would be the preferred way to try a live distro on it. Burning CDs… so archaic, but at least it works. I saw some BIOS settings related to that, and while they seemed correct, perhaps I should fiddle with them some more. But a live CD worked for now. The other boot issue is that my keyboard is often (but not always!) disabled at the GRUB menu. Today I found BIOS settings for that too. Honestly, who would ever WANT to disable their USB keyboard at boot? And why did it work sometimes? Well, whatever. If only that were the last of the tricks my motherboard had for me.

Having installed F17 and fiddled around a bit, it was time to try out virtualization. I wanted to give the OpenShift LiveCD a try, so I started up virt-manager. It crashed. I tried VirtualBox instead. It wouldn’t run either. The problem was, I didn’t have kernel sources and headers (kernel-devel and kernel-headers) to match my running kernel, in order for kernel modules to be built for virtualization. And when I looked at what was available in the yum repos, there simply weren’t any matches. I.e., no kernel versions matched any versions of header/source available. I would basically have to build my kernel from source to get a match.

I hoped that situation would resolve itself, and when I looked today, it had. New kernel-devel available to match the kernel. Onward and upward! I tried virt-manager. It crashed. I tried VirtualBox. It gave me an error: “AMD-V is disabled in the BIOS. (VERR_SVM_DISABLED)”. Grrr! So I looked up what this is all about. There are two levels of problem.

First, my Athlon 64 does support AMD-V (the flag in /proc/cpuinfo is “svm”). However, this capability can be disabled by the motherboard. In my motherboard, the Gigabyte GA-M61P-S3, it is disabled with no option in the BIOS to configure it. Why? Gigabyte has offered no explanation. Five years ago, someone ran into this exact same problem using Xen, and the only solution he found is downgrading the BIOS. Downgrade? Yes. The ability to disable this feature was introduced in later CPU steps, and taken advantage of in later versions of the BIOS. I would be curious if the problem was rectified in later BIOS versions after that exchange (latest releases are 2007/10 and 2010/08). Doubt it, since the notes there don’t mention it. Also, I was idly looking at getting the “new hotness” of an Athlon 64 X2, since the desktop speed is about as great as my crappy laptop, but that would require a BIOS upgrade, so moving in the wrong direction as far as virtualization (and I’m not sure I want to deal with the extra heat). Maybe a third-party BIOS would do the trick? Maybe it’s just time for better hardware. Sadly, AMD seems to be somewhat throwing in the towel against Intel. Can’t really justify backing the underdog anymore :(

Second, with AMD-V disabled, virt-manager was running into an SELinux violation trying to do non-hardware-assisted emulation. Took me a while to find that link, but it shouldn’t have been hard, given that’s exactly the error I was hitting. Too bad it’s not solved in F17. At least that one is easy enough to resolve! So I at least have QEMU to work with. It’s gonna be a dog, though.

Now, the two other major things I get to deal with: dealing with GRUB2 (introduced in F16, but I haven’t really used that) and the migration from SysV to systemd.

I saw GRUB2 at work when I tried Ubuntu a while back, but didn’t really recognize it at the time and ran screaming. I’m so used to just editing my GRUB menus directly, it seems so much more complicated. It’s a bigger leap than moving from LILO years ago. But I think I can begin to see some of the benefits. Also, it seems to be pretty good at detecting the existing OSes on the system and providing boot options for them. That’s nice, since I rarely work on a single-boot system anymore. I just need to spend a little more time with guides like this one to get the hang of it.

The transition to systemd was a rude awakening too. How do I turn on sshd? How do I configure the firewall so I can VNC and ssh in? (The firewall was particularly confusing since there was an abortive attempt at replacing that with something else which made it onto the beta but was reverted.) Fortunately it doesn’t look too difficult.

Wow, this was a pretty big release for Fedora!

Oh yeah. One more thing: how to get the desktop switching of the dual monitors to work the way it used to and obviously ought to: both monitors switch when you switch desktops. I read about that decision when Gnome 3 came out with F16, and it made no sense to me. There was some hackish tweak for getting it to work the way it should, but I can’t find it right now. It seemed totally unstable under F16 – gnome-shell would freeze randomly all the time. I hope this is better in F17. I’m not encouraged, though, by the fact that most of the gnome-tweak extensions I want to use seem to be broken at this time.

Fiddling around on Apr. 3rd

The “New Post” link at the top of WordPress goes to a new post form devoid of useful options. Now why would WordPress want to make that the standard?

Discovered today that some versions of Spring Insight (even developer version) wouldn’t deploy if the hostname it’s on doesn’t resolve properly in DNS. Doesn’t that describe most developer workstations? Version 1.5.1 doesn’t seem to have this problem though.

Discovered Eclipse/STS Window->Customize Perspective today. It lets me choose which things go on the top toolbar and the top menubars. It doesn’t let me re-order them, and it doesn’t seem to change the right-click context menus, but this does help clear up a lot of clutter. I don’t really use the toolbar – I should probably either remove it (can I do that?) or put really useful stuff on there. And now I kind of want to go through the list of items and find out what they all do…

I also got seriously derailed trying to change system appearance settings in Fedora. It really needs an “undo” button.

And I spent a bit of time fiddling with STS trying to bend the tc Server instances to my will. There doesn’t seem to be a guide anywhere to what all the terms mean. I think I’ll write one up tomorrow or sometime.

Broadcom wifi and Fedora

I bought my Lenovo G550 laptop with the idea that, while being fairly inexpensive, Linux would run well on it. And for the most part, that’s been true. Even the camera worked without a hitch. The main problem I had was that under Fedora 13, I couldn’t get the video to mirror to the SVGA output – the screen would just go black when I tried, rendering it useless for presentations. But that seemed to be solved with Fedora 14, so I chalked it up to temporary machine-specific weirdness.

The real problem since then has been the wifi. When I originally installed the box, I saw that the wifi wasn’t working. I ran lspci, saw that I had a Broadcom BCM4312 chipset, and found with a quick trip to Google that it needed some proprietary firmware (joy). There were some old articles on the net about how to do that by cutting it out of other drivers, but it seemed the modern way to do this is just to enable the rpmfusion repos and install kmod-wl. So I did that, and it worked. Problem solved and largely forgotten, for a while.

However, as far as I can recall, this never worked on Fedora 14. So I was stuck with either no wifi (Fedora 14), or no presentations (Fedora 13). I chose to run Fedora 13 for my personal hacking, and use the Windows boot (which naturally worked fine) for presentations. Then a month or two ago I updated Fedora 13, and wifi stopped working there too. Even if I booted an earlier kernel; under no version could I get it working. Windows of course still worked, so I knew it wasn’t hardware.

Fedora 15 just went GA a few days ago. I installed it yesterday, tried the same trick with kmod-wl, and glory be! Wifi worked! Mirrored video worked! I was back in business.

Then I found that my Gnome 3 desktop (which by the way… not sure I like… weird merger of Mac and Android) had gotten into a weird state, and ran a system update for bug fixes. Calamity! Wifi was back to broken – again, with either the original kernel or the updated one. NetworkManager failed to even run – it would start with a red mark in my toolbar, then just disappear. Maybe it’s not kernel-specific? Maybe it’s NetworkManager? I don’t know.

Well, I just installed again, and ran updates, and then installed kmod-wl (which looks like it might have pulled in an updated broadcom-wl for the new kernel), and it looks like the wifi is back up. But this is a lousy situation – I’m going to be fearing making system updates because my wifi will break :-( I’m not even sure who to complain to… the driver is 3rd-party, in fact so is the repo, so it’s not Fedora’s fault per se. On the other hand maybe the reason it keeps breaking is because Fedora moves too quickly and changes kernel APIs too much for the wifi firmware to keep up.

For now, I guess the solution is to dual-boot F15 with itself, and only update one at a time to make sure one is always working. (Or try Ubuntu, some of you will say; but I like Fedora, and they don’t share bootloaders very well.)

kudos to yum fastestmirror plugin

I don’t really understand why yum-fastestmirror isn’t just installed in Fedora automatically. Without it, I’ve had yum trying to get packages from across the Atlantic, which makes no sense. With it, my system installs and updates are about as fast as my internet service can handle, which is pretty sweet.

Until recently. Recently I noticed some updates crawling at dialup speeds again. Not sure how this mirror got designated as fastest, but it certainly wasn’t fast. Maybe it throttles intermittently.

So today I found another reason to love fastestmirror: you can exclude specific mirrors that you find sucking. Just edit /etc/yum/pluginconf.d/fastestmirror.conf and uncomment the “exclude=” line, and list any mirrors that suck (check the beginning of your yum session for what mirror it’s using) separated by commas. Your next yum run will be back to the usual speed. Win!

Im-a build me some Spring samples (Part 1: petcare) #fail

Just more examples of commonplace Eclipse/Java things that drive me nuts. I should say up front that the version of Eclipse I’m using is actually SpringSource Tool Suite (STS) version 2.3.2.RELEASE, running on the 1.6.0_20 64-bit Sun HotSpot JVM on Fedora 13.

There’s a trove of Spring sample projects over at https://src.springframework.org/svn/spring-samples/ – very helpful. So I had Eclipse check some out and import them as projects. Funny thing, there seem to be a lot of complaints about XML. I’m getting a little more savvy, let’s see if I can resolve these.

Pet Care

spring-petcare-3.0.xsd

From petcare’s servlet-context.xml, we get the good old “Referenced file contains errors (http://www.springframework.org/schema/petcare/spring-petcare-3.0.xsd).” OK – I’m pretty familiar with that. If you try to go to the URL given, SpringSource’s server redirects you to the home page. Seems the “petcare” schema just didn’t quite make the list with the rest of the framework – I can understand that. But what URL should we use instead?

Well, not surprisingly, the petcare projects contains its own XSD; it’s in /src/main/resources/org/springframework/samples/petcare/util/config/ – so how do I use that as the URL? Well, one way is to use the svn tree from the website; then the schemaLocation is https://src.springframework.org/svn/spring-samples/petcare/trunk/src/main/resources/org/springframework/samples/petcare/util/config/spring-petcare-3.0.xsd. Would have been nice if the project just did that, wouldn’t it? I would think that, distrusting SpringSource not to move/change it again, you could refer to it relative to src/main/resources/META-INF/spring/appServlet/servlet-context.xml as ../../../org/springframework/samples/petcare/util/config/spring-petcare-3.0.xsd (feeling the pain yet?) or copy it to the same directory and just refer to it as spring-petcare-3.0.xsd – but neither of these seems to work on deploy, while the web URL does. There’s a file META-INF/spring/spring.schemas that appears to be intended to specify where to look in the project for the schema, but I’m not sure how it’s supposed to be referred to in Eclipse to make this work.

Here’s a really great error Eclipse has on one of the XML elements that refers to the schema: “- schema_reference.4: Failed to read schema document ‘spring-petcare-3.0.xsd’, because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.” So which is it? Good grief. Would it really be hard to make messages like this actually useful? This is so frustrating.

Amazingly enough, if you try to deploy and you haven’t cleaned this up, Tomcat goes and tries to download the XSD as well and fails if it comes out wrong. So there you have it: your ability to deploy seems to depend on whether the right web sites are up at the right time. I imagine there’s a Tomcat or context.xml setting to disable this behavior.

Spring NamespaceHandler for petcare:resources

OK. So now I’m pointing at the right XSD, but I still have problems with servlet-context.xml. Actually it’s only a warning, but: “Unable to locate Spring NamespaceHandler for element ‘petcare:resources’ of schema namespace ‘http://www.springframework.org/schema/petcare'&#8221; – again with the “Unable to locate” business. That crap sure gets old. Why don’t you give me some kind of clue? Where did you look, where should I look? Actually I think I understand this and it’s trying to say there’s no “resources” element defined in the XSD. But there certainly is, so I don’t really know what this is on about. It seems to work anyway on deploy so I’ll ignore for now.

root-context.xml: Build path is incomplete

On to root-context.xml, another Spring bean file. This has three errors listed. The first two are really confusing: Next to line 22 which looks like this:

<!-- Embedded H2 Database -->

I have the error “Build path is incomplete. Cannot find class file for org.springframework.samples.petcare.users.PetcareAuthenticationFailureHandler”. Next to line 24 which looks like this:

<jdbc:script location="classpath:schema.sql" />

I have the error “Build path is incomplete. Cannot find class file for org.springframework.samples.petcare.users.PetcareUserService”. WTF? Actually Eclipse helpfully gave me a clue below on line 56, which looks like this:

<import resource="security.xml" />

This has the warning “Validation warning occured in imported configuration file ‘src/main/resources/META-INF/spring/security.xml'”. Yes, as it turns out that file has errors on lines 22 and 24, where  they make a lot more sense. But they’re not reported in security.xml; they’re reported against irrelevant lines in root-context.xml, which just includes it. Truly mind-boggling.

Now from this, plus the “Build path is incomplete. Cannot find class file for org.springframework.samples.petcare.util.templating.DefaultStringTemplateFactory” on line 29, I gather the build path is incomplete. But all those files look to be provided by this project and the build paths seem to be set up fine. So what the heck is going on?

At this point I checked my system and noticed that after installing some unrelated things, Fedora has chosen java-1.5.0-gcj as my compiler. I don’t think Eclipse is using this, and theoretically it shouldn’t matter anyway, but I shut down Eclipse, reconfigure alternatives so the Sun JDK is again providing the default javac, restart Eclipse, and clean the project. Somewhere in there, the complaints went away.

page.jsp Type mismatch

Now I’m left with just one actual error in src/main/webapp/WEB-INF/layouts/page.jsp. Only, when I open that file, Eclipse doesn’t list any errors. I have to go down to the “Markers” tab to find it:

page.jsp line 62 Type mismatch: cannot convert from boolean to String

Line 62 is a completely innocuous HTML div. Eclipse is just bonkers. I delete the marker and now my petcare project is free of red Xes. I deploy and it works. That might be enough for some people… but now, what about all those warnings?

Unresolvable warnings

Our old friend servlet-context.xml still has a warning next to <petcare:resources> that says “Unable to locate Spring NamespaceHandler for element ‘petcare:resources’ of schema namespace ‘http://www.springframework.org/schema/petcare'&#8221;. I feel I’ve been as clear as possible about the petcare schema so I really don’t know what more there is to say. So let’s leave that (or delete it).

Under src/main/resources, log4j.xml complains “The file cannot be validated as the XML Schema “/home/luke/Documents/workspace-sts-2.3.2.RELEASE/petcare/src/main/java/log4j.dtd (No such file or directory)” that is specified as describing the syntax of the file cannot be located.” This seems to be universally ignored – as I recall, I saw some bogus explanation as to why it was bad to specify a URL for this DTD. You would think Eclipse could just supply the DTD itself, or find it somewhere in the log4j JAR in my Maven dependencies. I don’t have a clue what to do about this so I leave it.

The final warnings are in src/main/webapp/WEB-INF/views/appointments/calendar.jsp, where Eclipse is complaining about data-* attributes on some HTML tags. As I recall these attribute “extensions” are part of the HTML standard so I don’t know why Eclipse is complaining. No way to shut it up without disabling validation entirely, so again let’s leave it. And that’s it for petcare.

Memory (classloader) leak

BTW, petcare has a big fat memory leak in it somewhere, because after you’ve re-deployed a few times, you get a PermGen error. Nice going. I can use this to hone my memory-leak-debugging skills soon.