« We get signal? | Home | More on removing the desktop c... »

For great justice

Sat 18 Sep 2010 by mskala Tags used: , , ,

I'm not planning to post further continuous updates on my move to the new computer, but at least one correspondent commented that she hadn't seen any further updates in a while and hoped the new machine was working, so I thought I'd better wrap up some loose ends.

The new machine works. It will be a long time before I'm fully "settled in" on it, and a lot of software that used to work, doesn't work now because of the change. I will be fixing things as they come up, one at a time. But I've moved over my home directory, email is flowing in both directions, and a snapshot of the old machine at the time of the crash is now archived to DVDs, independent of my other backup measures. I'm basically back in business. A few loose ends and other comments, below.

If the mail I just got is to be believed, TigerDirect is refunding the full price of $274.99 on the RAM modules that didn't work. The mail's wording is not entirely clear. I'm not sure whether they'll also refund the tax; I'm pretty sure they won't refund the shipping in either direction. So I may end up unreimbursed for about $60 of taxes and shipping (my estimate from the actual amount of shipping back to them, plus the total amount of shipping and tax on the entire order scaled to the fraction of it that was returned). Meanwhile the replacement RAM from Canada Computers cost me $198.86 including taxes. I think the G.SKILL RAM may be considered more of a "cheap" brand, but the Corsair modules aren't high-quality for me if they don't work, so the switch to G.SKILL can't be called a downgrade. On a dollar basis it looks like I end up ahead of the game by $15; but of course there's the inconvenience of an extra day of down time, and the running around resolving the solution, so I don't feel like I won.

In the final analysis (assuming the payment does come through) I'd say I am satisfied with TigerDirect's handling of the situation, and I'm content to continue doing business with them. I wish their site had made more clear that the "for Intel" modules wouldn't work with my AMD board, but it's possible that's not even the real reason they didn't work (motherboards and RAM are often finicky about each other), it could be to some degree my fault I didn't guess there would be a compatibility problem, and TigerDirect acted reasonably about the situation.

There's a lot of software I'm going to have to recompile, because very much of what I do is stuff like computer science research that isn't within stock Slackware, nor any other standard Linux distribution. I could just copy the binaries over from the old system and hope, but I want it to be really right. First order of business in this category is probably recompiling the kernel.

My online astrological chart service is still down, and it will be probably a week or two before I get it running again, because it requires a bunch of fairly large software packages (LaTeX, Apache, and Swiss Ephemeris) to all be fully operational. LaTeX and Apache came with the new installation, but will each require careful reconfiguration; Swiss Ephemeris needs to be reinstalled. But I do intend for the chart service to survive.

My apartment is now a disaster area, with little bits of working and non-working computer stuff all over everything, because my priority in this adventure was getting things working soon rather than keeping the space tidy. I have to go through it all, figure out what's worth keeping for spares and what's really garbage, put the stuff I'm keeping in some better form of storage, and figure out how to dispose of whatever I'm not keeping. The decommissioned sphere case, for instance, contains a couple pounds of aluminum and it'd be a shame to dump that in the regular garbage; but I'm not sure I'm up for spending all the time removing the steel screws holding it together and the plastic bits glued to it, and once I do that, I don't know where one actually takes a couple pounds of scrap aluminum for it to be recycled.

I've designated a logical volume on the new system specifically for the SVN repository, and it's my plan to move my major creative projects (both software and writing) to that. One of my friends, a software engineer, was shocked when I said I didn't have the book in SVN; but the thing is, for that or any project, including software, on which I'm the only worker and I work on it in just one place, SVN only seems to get in the way. The response to "But what if you make a mistake and want to go back to an earlier version?" is that I try to make very few mistakes; and I make backups, which cover that kind of scenario. The response to "But what if you want to fork it and maintain parallel versions?" is that I never do want to do that.

However, I think the situation may have changed in such a way that now SVN does make sense. The big thing is that now I'm working on the book from two different machines, the laptop and the desktop, without a constant network connection between them; it'd be nice to have something smarter than rsync for keeping the working copies up to date with each other. When dealing with publishers and editors it may even be appropriate to do branching, for use cases like "Okay, you insisted I take out the catgirl bondage chapters, but some day when I'm famous, readers will want to see those, so I'll maintain another branch in the repository." But getting the SVN server installed as I want it to be means a dependency on Apache, so I have to get that up and configured first.

I also hope to do more academic collaboration in the future, and since I may be moving around a lot, it's valuable to have an SVN repository that I control myself and can give others limited accounts on; and for use with the laptop, I want to be able to connect to it securely, even on wireless connections that block SSH. That's the reason for setting up an Apache/SVN server instead of a simpler option.

I have to go through and re-do all the international (mostly Japanese) configuration again, because I'm on a new version of KDE now. I'll probably also upgrade KDE to the latest and greatest, because the one that came with Slackware has annoying bugs like not being able to adjust the size of the icons in the panel. And of course, I have to re-install I Hate the Cashew!. I have mixed feelings about KDE4 in general. It seems like there are an awful lot of new annoyances like the cashew, this icon business, the huge-ass tooltips, the impossibility of manually hiding the panel, and the forced adoption of this "Semantic Desktop" bullshit. I also don't like the KDE developers' attitude, which seems to be new with version 4, that of course all users want a dumbed-down interface with exactly the configuration the developers like best for themselves, and users should not even be given the option for anything else. You should have seen what KDE4 tried to do to my laptop's UI!

And I really, really hate the general assumption that it's okay for mouse cursor position to be significant without a click. That is never okay. Nothing should ever pop up because I moved the mouse, except maybefor very small, unintrusive tooltips; no menu should ever go away because I moved the mouse off of it; focus should never be selected by mouse position alone; the corners of the screen should not be "active". KDE offers a special utility to make it so that if you stop moving the mouse for a certain length of time, it will automatically click. Putting that on the "accessibility" menu is a sick joke. It's a simple, basic, easy rule that the mouse does not exist when I don't press the button. Why is this so hard for developers to wrap their heads around? I am talking about the standard PC/Mac-derived user interface I'm using, to which "mouse position is significant" is a foreign, inconsistent, and extremely unwelcome recent addition. I'm aware that other user interface paradigms exist, including the very old X Window System tradition; but I don't think that's where these annoyances descend from. Maybe it comes from people who don't actually type on their computers, and so they think that they can move the mouse where they want it, then move their hands to the keyboard and use that, while leaving the mouse where it is and having it stay there. My reflex is to shove the mouse out of the way when I'm going to type - I do that, without thinking, easily a couple hundred times every day - and the "mouse position is significant" assumption means I end up cursing frequently, because now shoving the mouse out of the way breaks everything. Maybe these people, in turn, don't type because they've stopped using command lines. Just a guess.

Unfortunately, enough applications I want to run require KDE version 4, that I don't think it's tenable to just stay on KDE3. And if I'm to use KDE4 and have a reasonable chance of fixing the worst brain damage, that means I have to be running the latest and greatest version, which is the only one for which patches and support are available.


You may want to adopt configuration management tools, i.e. Chef or Puppet. I use Chef, because it uses git and Ruby heavily and I am familiar with both, but both are good tools.

There is more time involved in maintaining code to generate your system configurations, but if you move around from system to system, or upgrade every few years, the extra time might be worth it. I find it to be that way. It's especially nice to have around when a botched system upgrade blows up everything: when that happens, I can just wipe the installation and rebuild it from the configuration scripts. Depending on the severity of the fuckup, it can take less time than diagnosing what went wrong.

Chef: http://opscode.com/chef
Puppet: http://www.puppetlabs.com/puppet/introduction/

As far as the KDE4 mouse behavior goes, I haven't been able to replicate that on Kubuntu. Maybe it's some packaging weirdness? trythil - 2010-09-18 18:10
I find it hard to believe that you really can't replicate the mouse behaviour I'm complaining about, because it is a *general design principle*, not a bug in one specific thing. More likely, you don't recognize what it is I'm describing. Some examples of what I mean, in my KDE 4.4.3 installation:

* Position the mouse cursor over almost anything on the panel (for instance, a launcher icon or an item in the task bar) and wait. After about a second, a huge tooltip appears. Move to something else, without clicking. That huge tooltip disappears and some other one appears. (Actually a bug: on my current installation, sometimes the place where the old tooltip was, gets filled with part of the desktop wallpaper instead of redrawing the window properly; but my complaint is about the fact that the tooltips appear at all, which is clearly deliberate and not a standard "bug.") My desired behaviour: for things not to appear without my requesting it.

* Click on a menu on the menu bar in any KDE application. The menu opens. Now move the mouse around, without clicking. If you move it over the name of some other menu, the menu you selected closes and the other menu opens. If you move over items in the menu that correspond to submenus, the submenus open and close, all without a click. My desired behaviour: for things not to appear or disappear without my requesting it.

* Look at the upper right of an empty desktop. There is a weird icon there, overlaid on your wallpaper. Move the mouse cursor to it and don't click. A huge tooltip appears. My desired behaviour: not to have this icon nor the features it enables.

* This depends on your configuration: move the mouse to the bottom of the screen. In what I think is the default mode, the panel appears (causing other windows to resize) and disappears when you move the mouse away from it, all without a click. My desired behaviour: for things not to appear or disappear without my requesting it. This point can be adjusted (open the panel cashew, open the "more settings" menu, select "always visible" from the "visibility" section) but in that case, it becomes impossible to hide the panel at all. There is no way to manually hide the panel without making it sensitive to unclicked mouse position, short of deleting it entirely.

* Special bonus: try to make a window exactly cover the right-hand half of the screen. If you pop up, say, a Web browser, it may typically appear on the left. Grab its title bar and move it so it snaps into the upper right corner of the screen. Whoa! It just maximized! Un-maximize it and it goes back to being on the left. Just try to get it into the upper right without maximizing it. (This is a configurable feature, set under "System Settings" -> "Look & feel" -> "Desktop" -> "Screen Edges" -> "Maximize windows by dragging them to the top of the screen." It appears to be turned on by default.) My desired behaviour: for windows not to change size unless I tell them to.

I don't think it should be hard to recognize the general principle at work here... Matt - 2010-09-18 18:35
Because Al has a low melting point I think a lot of small industries recycle it - but then you have the problem of finding the right small industry where you can take your two pounds. As for your further remarks - the trend of software designers assuming they must do all the thinking for the software consumer seems to be gaining ground. It is scary. Axel - 2010-09-18 22:40
Tony H.
On KDE4 - I sympathize, but I'm puzzled. You say 'I am talking about the standard PC/Mac-derived user interface I'm using, to which "mouse position is significant" is a foreign, inconsistent, and extremely unwelcome recent addition', but this is mostly what distinguishes the Windows 95 UI from the earlier CUA-style OS/2 Presentation Manager, and the CUA subset implemented in Windows 3.1 and such. In Windows today (well, XP I'm looking at just now), when I click on a menu bar item, it behaves exactly the way you decry above. There is some rule that requires an initial click, but then the menus open and cascade on mouse movement alone. No initial click for tooltips, and some other things. I remember being outraged over this too, but that was in 1996 or so, and my fingers have got used to it to the point that the platforms where you have to hold the button down now seem weird and foreign.

It's tempting to think that (e.g.) KDE4 has crossed some line of wrongness wrt mouse position significance, but I think that line was mostly crossed elsewhere a long time ago. Even things like corner behaviour are widely implemented by add-ons to the MS GUI from mouse and touchpad vendors, according to their own whims.

I find myself thinking the same when I encounter things like Windows 7, or various MS apps like the unspeakably evil Zune player (it outdoes even iTunes for lack of well-behavedness on several levels) which among other things redefine the very nature of a window, rather like Facebook's perversion of screen elements you mentioned a while back.

Well, I know - I'm talking Windows a lot here, and you're talking KDE. Maybe some of their recent changes have to do with appealing to a putative Windows crossover crowd. At least in the crunch you can change it. Tony H. - 2010-09-20 14:39
It's a long time since I've used anything but Linux on a regular basis, and the GUI I used before switching to Linux was, in fact, OS/2 Presentation Manager. So when I say "a recent and unwelcome innovation" it could still be as much as 15 years old - though its introduction to Linux in particular is, I'm sure, more recent than that. I don't know where Windows is at right now. I don't think Macs behaved as I describe, as of the black-and-white Mac era, and I suspect that that was by design.

However, you seem to be focusing especially on the menu-bar menus in particular, and that's the least of my complaints. Although position sensitivity in that specific context does annoy me, it annoys me much less than the creep of position sensitivity into other things - such as the huge tooltips, the panel auto-hide, and "maximize windows by dragging them to the top of the screen." I'm aware that Windows also does panel auto-hide and probably did it first; and as you describe, Linux-based and other GUIs have had position sensitivity in the menu-bar menus for a long time. They haven't had it as a general design principle everywhere, though.

If you want me to point to one specific thing that constitutes a line KDE4 has crossed, I think it might be the huge-ass tooltips; but even that's a bit fuzzy, because many systems have had tooltips of some sort for a long time and those don't tend to annoy me. Maybe one factor is that the KDE4 huge-ass tooltips don't appear right where the mouse is like the older Windows-like tooltips. As a result, the KDE4 tooltips tend to pull my attention away from whatever I'm doing, and that makes them more distracting. Another factor might be that they "chase" the mouse relatively slowly - introducing movement that draws the eye and, again, makes them distracting.

Rather than saying a line has been crossed, I think it'd be more accurate to say that there has been an ongoing slide for a long time into position-sensitivity being generally acceptable throughout computing, and KDE4 has made such a big step down that slope that it feels like a qualitative difference.

Note I'm also annoyed by the trend, which has been going on for a long time, for Web pages to use scripts to make themselves position-sensitive. Matt - 2010-09-20 15:17
Did you bleed on it yet?


"The response to "But what if you want to fork it and maintain parallel versions?" is that I never do want to do that."

So you're not writing a choose your own adventure novel? Owen - 2010-09-27 01:59
I don't think I've bled on it yet, so I guess the new installation isn't quite complete; that'll probably happen sooner or later, though.

It's true that I'm not writing a CYOA, but as you probably know, that's not what version control is for anyway... Matt - 2010-09-28 11:07

(optional field)
(optional field)
Answer "bonobo" here to fight spam. ここに「bonobo」を答えてください。SPAMを退治しましょう!
I reserve the right to delete or edit comments in any way and for any reason.