madewokherd

Why I'm not switching from Linux to Windows 7

Sun, 01 Nov 2009 04:00:43 GMT

So I've been using Windows 7 for part of a day. I've set up the software I'd normally be running (so far all communication software of some sort, really). I have no major complaints about the desktop.

I really like the new taskbar. I found it immediately intuitive and much better than the standard "one wide button for each window" deal. (In case any OSX fans want to point at the dock, I'll say that I find the OSX dock completely unintuitive and much worse than the standard "one wide button for each window" deal.)

I no longer want any programs I use to minimize icons to the tray. I have as much space as I need in the normal taskbar. I can easily find the applications I want there, by the large icons, as well as their individual windows, by the previews. I'd even consider turning off tabs in my programs.

So really the desktop has one major advantage and a lot of minor pros and cons. If it were only about the desktop for me, I'd seriously consider switching.

There is one major problem with Windows that stops me from doing this. It is hard to develop cross-platform software on Windows, and it is very easy to develop cross-platform software on Linux.

Just about everything I write runs on multiple platforms. This is actually very easy to do on Linux. Just create as few hard dependencies as you can, and make sure the things you depend on are cross-platform. For me, that often means pure standard C or pure standard Python. If I need a gui, I bring in GTK. Rarely do I add any other hard dependencies.

I know that it's possible to do all of those things on Windows. I can install mingw, Python, a development version of GTK, Git (gotta have source management), SCons (gotta have a build system), pkg-config (else how would SCons know how to link to GTK?), and PyGTK (with its many dependencies). The problem is that getting those things installed and working together, then keeping them updated and working together, is difficult. On Linux, I tell my package manager to grab those things once, and they are working, integrated, and updated forever.

Of course, there are various Linux apps, features, and quirks I'd miss, but I could easily deal with all of them except this. Right now I have a development platform that Just Works, and I don't want to give it up.

The Windows 7 EULA has a Wine clause?

Sun, 01 Nov 2009 00:06:15 GMT

I installed Windows 7 today. Naturally, I read the EULA. It was long and included many things I thought weren't very relevant, almost as if they don't really want me to read it at all.

Among many other things, it said this:

"You may not [...] use components of the software to run applications not running on the software;"

I may not use what for the what what?

At first I took it to mean this:

"You may not run emulators in Windows 7."

An emulator running in Windows 7 would use components of Windows 7 (as all applications running in Windows 7 do) to run applications on some other OS.

But they can't possibly mean this.

My next thought was that maybe they mean this:

"You may not use .dll files from Windows 7 (or other components we haven't thought of) to run applications in Wine (or other similar things we haven't thought of)."

Of course, very few people do this anymore. Most of the components you would want to use are actually redistributable libraries (not really part of the OS at all, I'd argue), ideally shipped with the applications. When they're not, they have installers you could run.

Still, it's interesting that they're putting restrictions in their EULA specifically for Wine.

(Or is this really about something else that I've missed?)

sigh, Chrono Trigger: Crimson Echoes is dead

Wed, 10 Jun 2009 00:55:56 GMT

You must read http://crimsonechoes.com/ to get the context for the rest of this.

I haven't watched any of the videos because I'm still way too upset about this thing. I'm hoping if I write about it, maybe I can get over it and watch the videos.

Chrono Trigger (and later Chrono Cross) consumed a non-negligible chunk of my life in college. I pirated Chrono Trigger (I had missed it in the SNES era), but I did buy a copy of Chrono Cross (which I played on an emulator; I didn't own a Playstation at the time). I LOVE both of those games. I cannot coherently discuss why this is. I just love them.

Now that Chrono Trigger DS hadn't been released when I first started playing Chrono Trigger. If it had, I might have picked it up (and certainly wouldn't have pirated the SNES version). Well, I'm certainly not going to pay for it NOW.

OK, so, first of all, there's no obvious reason why Crimson Echoes would violate the copyright on Chrono Trigger. Naturally, the developers distributed it as a patch, a set of instructions to convert the original program (Chrono Trigger) into a new program (Crimson Echoes). Nothing from the original program was distributed by the developers.

The developers (Agent 12, who I read is the director of the project, talks as if it's his sole decision; I don't know is this is accurate, and for my purposes that's not very important) have decided to avoid a legal battle, even though they appear to have done nothing illegal. Nor is it reasonable to ask them to. The CE developers were planning to give their work away. For their would-be benefactors to complain that they aren't working hard enough to do this is simply irrational. Even though I fully understand this, a part of me irrationally wants to make exactly that complaint.

(I can also understand why we'd see old copies of this thing being distributed, but that IS illegal. The CE devs have a copyright on their work, and they have not given anyone permission to distribute it.)

If I had heard that the CE developers had lost interest or simply could not find the time to work on the project, I don't think I'd be upset. Those are good reasons to never release a free thing.

What upsets me is that it is not being released for a stupid reason. Someone at Square decided (probably incorrectly) that this was a violation of their copyright and (also probably incorrectly) that it was in their best interest to stop it while they could.

Mr. Square Enix Legal Department, just because you can do something, that doesn't mean you should. CE can't hurt you now, but now it can't help you either. Why did you think it would hurt you? You lose. The CE team loses. Society loses.

I just don't understand why companies (or is it just Legal Departments?) are threatened by this sort of thing. Certainly, there are other things I could be more rightfully upset about (like the fact that there are STILL HOMELESS PEOPLE IN MY CITY; seriously, why haven't we fixed that yet?), but people worked hard on this thing, and it should be out where it is useful to people.

Possible non-broken approach for sandboxing in Python

Mon, 20 Apr 2009 05:58:28 GMT

Some time ago, Guido described why sandboxing in Python has not worked well so far: http://neopythonic.blogspot.com/2009/03/capabilities-for-python.html

Since reading that, I've come up with an idea that seems like it could work (or, more accurately, I applied the existing idea that is Mandatory Integrity Control to this situation). Now, I have no actual experience with Python at the C level. I have only a vague understanding of how it works. Maybe this is completely impossible. If it is possible, I'm not the one to do it. Also, I'm not on any relevant mailing lists, nor would I be able to follow a thread.

So I'm just going to put this on the Internets, and maybe someone will see it and follow up or maybe not.

First, we define a thing called a "security domain". In general, information is allowed to flow from more secure domains to less secure domains but not the other way around. The most secure domain is created when the program starts and is called AppDomain.

Every object in python - code, classes, stack frames, lists, exceptions, everything - has a domain associated with it. Usually, this domain will be AppDomain.

Naturally, there would be a Domain class, which you would call to create a new domain.

sandbox = Domain()

This will result in a Domain object that resides in the current domain.

If you want to execute some dangerous code, you do it like this:

def run_a_thing(s):
    exec s
result, exception = sandbox.call(run_a_thing, "print('I will cut you.')")

The sandbox.call function will create a new stack frame, "demote" that stack frame so that it resides in the sandbox, and call the function with the given arguments.

If a stack frame tries to exec something that is in a lower security domain than the stack frame is in currently, this causes an exception.

Stack frames can never be "promoted". If a stack frame executes code that resides in a higher domain, it stays in the sandbox. There aren't any magical exit functions. The only way to get out of the sandbox is to raise an exception or return something.

Functions defined in C will not be called unless the stack frame resides in AppDomain or the function has set some sort of domain-aware flag. Failing will cause a SecurityException. C accessors for built-in data types (list, str, dict) will ideally also raise a SecurityException for objects not in AppDomain, or if that's not possible they will return some dummy value.

That should start us off with a sandbox that can do absolutely nothing. If it can somehow do something, it's already broken and I give up.

The next step is to make a whole bunch of builtin functions use accessors that can deal with sandboxes. If they create new objects, they should assign those new objects the security domain of the current stack frame. If they have to access objects in a lower security domain than the current stack frame, they will raise SecurityException. If they have to modify objects in a greater security domain than the current stack frame, they will raise SecurityException.

Therefore, any classes, instances, functions, or code objects created in a sandbox are automatically marked as belonging to that sandbox. If you accidentally call a function created by a sandbox, that will raise a SecurityException.

No builtin function that talks to the outside world can set the domain flag or use the accessors that don't fail for things not in AppDomain.

So the print call above would fail, as print would not be one of the special functions that works in a sandbox.

Now, suppose I want to actually do something useful: call a function with a floating point and get back a floating point result. I want my function to be arbitrary python code, but I also don't want it talking to the outside world. Maybe I have untrusted code that looks like this:

code = """
def f(x):
    return x+1
return f"""

I can call it like this:

untrusted_function, exc = sandbox.call(run_a_thing, code)

Later in my program, I might decide to call the function like this:

untrusted_function(1.0)

That will fail. In order to call that function, I have to access its code object. The function is in a lower domain. Therefore, I CANNOT access the code object. This is simply not a legal way to call it.

But I have to get the result somehow, and I'm sure it's a perfectly harmless float. So here's how I do it:

result, exc = sandbox.call(untrusted_function, 1.0)
result = sandbox.promote_float(result)

The promote_float method function will call float() on the given object from within the sandbox, then (if the result is a float) return a float in the current domain.

I am forced to explicitly state that I am expecting a float and put a conversion in there. I am also limited in the types I can "promote".

I imagine this can make for a confusing case. Floats, like some other immutable types, can be cached ("1.0 is 1.0" in python may sometimes be True). Conceptually, the cache belongs to AppDomain, so any domain can access it (but not write back to it). That means the function may already return a float in AppDomain. If this happens, the result of the above call can be used directly, without calling sandbox.promote_float, and an application bug may go undetected.

Now, for fun, I'm going to pretend this thing exists and write a wrapper class so I can pretend to be able to sandbox generators:

# This list functions as a special return value indicating end of iteration.
# We could use any object, as long as it's visible everywhere.
stop_iteration = []

class iterator_within_sandbox(object):
    def __init__(self, code):
        created_locals = {}
        exec code in created_locals
        self.iterator = created_locals['iterator']

    def __call__(self):
        try:
            return next(self.iterator)
        except StopIteration:
            return stop_iteration

class sandboxed_iterator(object):
    def __init__(self, code):
        self.sandbox = Domain()
        self.iterator, exc = self.sandbox.call(iterator_within_sandbox, code)
        if exc is not None:
            # Rather than devise a way to meaningfully print a sandboxed exception, raise a new one
            raise Exception("exception in sandboxed code")

    def __iter__(self):
        return self

    def __next__(self):
        result, exc = self.sandbox.call(self.iterator)
        if result is stop_iteration:
            raise StopIteration
        elif exc is not None:
            raise Exception("exception in sandboxed code")
        else:
            return self.sandbox.promote_float(result)

automated tests

Thu, 09 Apr 2009 07:05:19 GMT

2 weeks ago, I made a bunch of changes to Aisleriot games to appease a new automated test program I wrote. The idea was mostly to find crashes and other oddities (such as empty moves in the undo history) before users do. All the crashes and serious bugs were fixed earlier, and the 2-weeks-ago changes are minor things going to the development branch only.

When I ran the tests today, they told me that Labyrinth was crashing. Apparently, I had made a logic error in one of my earlier changes, and it introduced a crash bug.

I don't know why the test didn't catch this 2 weeks ago.

I made this change in response to a minor test failure (empty undo move), and it caused a crash. It was my error, but it was inevitable given the number of minor things I've been trying to fix.

But then the tests did catch this before any user did, and before it went into a stable release.

So overall, I can't decide whether I've won or lost here..

skip this one

Sat, 14 Mar 2009 20:29:10 GMT

Wine releases about every other Friday, subject to Alexandre Julliard's whims and vacations. Each Wine release is essentially a snapshot of the Wine Git tree from that Friday. Sometimes Julliard commits things the same morning so that no one has time to properly test it before the release.

Every once in a while, Wine has something that I call a dud release, a release that is drastically worse than the previous one. Wine 1.1.12 was the most recent one: http://www.winehq.org/pipermail/wine-devel/2009-January/071735.html

Wine 1.1.12 was released on Friday, January 2. Somehow Dan Kegel knew the next day that it was a dud.

Ubuntu doesn't package the 1.1.x versions of Wine. They, at least, were safe. There is a repository containing new Wine releases for Ubuntu, and I believe it had 1.1.12 for the two weeks that 1.1.12 was newest. That's fine; those people know it's beta software.

Gentoo had 1.1.12 as its "stable" version of Wine months later, when they should have known better. The newer versions were considered too new to be stable, yet somehow 1.1.12 was OK. I am forced to conclude that Gentoo defines "stable software" as software that is at least a few months old, regardless of whether it works or not.

Anyway, this sort of thing is to be expected when you release code that is basically untested. I think it's a little suspicious that two major regressions lined up in this way, but it could easily have been chance.

Ubuntu had, in 8.10, something that looked to me very much like a dud release. I've had a few major hardware failures. My work machine failed to boot because it couldn't detect my hard drives within a time limit. I learned later that I could work around this by pressing Ctrl+D. Once it did start, my CD-ROM drive didn't work.

OK, that was probably chance. Hardware regressions happen all the time, and they just happened to affect my hardware that time. No big deal.

There was another major regression that I know affected everyone: session management stopped working.

Session management on the Linux desktop does two very important things:
* It notifies the running programs when you are logging out, giving them a chance to ask you to save your work before the session ends.
* It can, at the user's request, "save" the current session, to be restored at the next login. It does this by asking all running programs to give it a "restart command". Theoretically, if the programs support it properly, all of your windows will reappear next login, in the same location as when you last saved.

I had my computer configured to save the session every time I log off.

Session management works through something called XSMP. It's an old, Unixy standard that communicates through something called ICE.

As it happens, gnome-session developers had been working on a rewrite. One of the goals of this rewrite was to provide a new session management protocol that would work through D-Bus. They were in the middle of the rewrite during release time, and they hadn't yet implemented XSMP.

The newer D-Bus protocol was in the rewrite, but it hadn't been stabilized. gnome-panel used it, but every other package that expected session management relied on XSMP.

If you happen to be running Ubuntu 8.10, you can observe the breakage by doing the following:
* Open the Text Editor.
* Type in some text.
* Log off.
* You will not be asked to save your changes.

I think most people who noticed this probably noticed it because their saved sessions weren't being restored.

So Ubuntu suffered a major regression. That sort of thing shouldn't generally happen. It did happen because:
* The gnome-session developers did a major rewrite in trunk. The new gnome-session was advertised as the latest and greatest version, and thus other parts of gnome could depend on it. I don't know why they did this.
* The rewrite wasn't ready in time. This is because no one was working on XSMP.
* The unfinished rewrite was released as a stable version when it came time in the cycle to release stable versions. I don't know why this happened. Maybe they had to release the it because gnome-panel needed the new protocol. Maybe it just hadn't occurred to them that they can release something other than the current state of trunk.
* The GNOME release went on as scheduled. This was probably because no one had been working on XSMP, and fixing the bug would've taken too long.
* Ubuntu packagers put the new gnome-session and gnome-panel in 8.10. I'm sure the packagers knew about this because the bug was in launchpad before 8.10 went live. I don't know what went into their decision.

According to the GNOME bugzilla, some distributions kept the old gnome-session and gnome-panel.

In the following development cycle, Lucas Rocha stepped up and did the initial work on XSMP, which he committed to trunk. Naturally, this code was new and somewhat broken, but it's a great improvement over nothing at all and makes further work much easier. In the last few days, Vincent Untz has done some further work on top of that. Said work has not been committed because of how close it is to release. While it has fixed some bugs, it may have added new bugs that are worse. We simply don't know yet; new code needs testing and time to mature.

So again gnome-session has been caught releasing at a bad time, and the resulting GNOME release will be bad. Said "bad time" has probably lasted about a year. I'm tempted to say "Get it together, gnome-session developers!", but really I think the bad decisions have already been made and the current state of things does not reflect on whether the gnome-session developers have it together at this time.

However, I would like to say this to advocates of time-based releases, anyone involved in this fiasco, anyone who releases software, and really anyone who will listen:

A "stable release" does not mean a release containing old code. It means that you are reasonably certain that the code is not broken and could honestly recommend that I use it in a production environment. If you can't release something that isn't broken, do not make a stable release.

If you have a release cycle with a development phase and with a code freeze (so that all code is tested in the wild for some minimum amount of time), you know whether your software is broken. If you release broken software because it happened to be broken during the code freeze, your release cycle is worthless.

GNOME 2.26, unless it reverts a lot of code back to 2.22, and whether Vincent Untz's recent work is included or not, will be broken because of gnome-session. Ubuntu 9.04 will probably bring in the new broken code from GNOME (it is probably better than the broken code that's in 8.10). GNOME and Ubuntu, I know that you are not individuals and that it is unreasonable for me to ask things of you as if you are, but I still would like to ask that you either fix your new release, delay it until it is fixed, or do not call it a stable release.

The Lucca WM news feed is moving, google group and irc channel created

Fri, 02 May 2008 23:45:46 GMT

I'm trying to fix the channels of communication for this project while it's still incredibly easy to do so. That means several things:

After this one, I will no longer make posts to this blog with the "luccawm" tag. New releases of Lucca WM will instead be announced at this google group: http://groups.google.com/group/lucca-wm-announce.

I have also set up a group for discussion. It is open to the public, its archives are open to the public, and you can post to the list without being on the list. That is at http://groups.google.com/group/lucca-wm-discussion.

I've moved the GIT repository for the source code from my own web host to http://repo.or.cz/. They actually support the GIT protocol so I think things will work more smoothly for people trying to clone the repository from there. The public url for the repository is git://repo.or.cz/luccawm.git, and they have a web interface at http://repo.or.cz/w/luccawm.git.

And finally, I've set up an irc channel, #luccawm on irc.freenode.net.

Lucca WM 0.1.1 released

Tue, 15 Apr 2008 21:24:39 GMT

This is a bugfix release for the tiling window manager Lucca WM.

Some memory errors from valgrind and a bug in the titlebar drag-and-drop code that would lock down the mouse and keyboard have been fixed.

This is version 0.1.1: Source (.tar.gz), Source (.tar.bz2), Ubuntu 7.10 x86 Binary (.tar.gz)

Lucca WM 0.1 released

Tue, 01 Apr 2008 21:46:51 GMT

I am announcing the first release of the tiling window manager Lucca WM.

It's a window manager that lets you arrange your windows in layouts where they do not overlap and where there is no empty space. This means that when you resize one window (tile, technically), the rest of the layout changes to adapt.

My main goals here (and why I think existing window managers are not good enough) are a shallow learning curve, flexibility (the user needs to be in control of the layout), and compatibility with modern Linux desktop environments, especially GNOME.

This is something I've wanted to do for a while, pretty much since I started using Ion. I wanted something that was like Ion without being so complicated or messing up my panels.

I was able to work on this as my senior project for the Computer Science department and a research project at Penn State Behrend. I don't think I'd have been able to do this otherwise.

Anyway, here's version 0.1: Source (.tar.gz), Source (.tar.bz2), Ubuntu 7.10 Binary (.tar.gz)

last.fm is incredibly cool

Sat, 07 Jul 2007 20:17:47 GMT

Ok. So. Last.fm is a personalized radio and music recommendation service. You can sign up for an account, and they will do all kinds of neat stuff like track the music you listen to and build a profile from it. And make a radio station of similar songs.

Anyway, they now have two features that are particularly nice for me: the web-based player (meaning I don't need special software to listen to the radio) and personal tag radio (meaning I can maintain a list of artists and create a station that plays music by those artists). It also lets me embed the station in this page, like so:

why Wine seems to suck more than it does

Thu, 05 Jul 2007 06:48:38 GMT

I was thinking about the problems people tend to have with Wine and how/if winebot can help (or how/if the problems should be fixed in Wine), and figured it might be good to get these thoughts down. People have trouble with Wine for a lot of reasons, most of which are not bugs in Wine. So, uh, without worrying too much about flow, here's a list:

Not everything works perfectly, and work-arounds can be complicated. This is one of the problems winebot is supposed to solve. Many applications will install and run just fine on Wine, once you apply this patch or move this file here or set these DLL overrides or whatever. Yes, the Applications Database has many wonderful guides, but as careful as the writers of those guides may be, communication isn't perfect. This isn't just a problem for new users. I think I'm a relatively experienced user of both Linux and Wine, and I have misunderstood guides.

In fact, the mere possibility of misunderstanding is a problem whenever things don't work. If we had a kind of guide that couldn't be misunderstood and therefore was always followed perfectly, we'd know that something else is to blame when something goes wrong and wouldn't have to waste time checking for misunderstandings. Winebot can provide this in the form of application packs.

Work-arounds don't exist for all non-working programs, and finding them is hard. Wine works pretty well for a lot of programs without any hacks, and it works pretty well for some popular programs with hacks. This probably leaves out many users of more obscure programs that could work if we just knew the magic set of steps that would make them happy.

Note that I'm only talking about programs that ALMOST work. If programs REALLY NEED something that Wine doesn't implement, then the only solution is to implement it (or in some cases use DLL overrides to steal it from Windows).

The real difficulty here is identifying what exactly causes a program to work differently from Windows (such as crashing when it starts). Once that's done, IF it turns out the program doesn't need very much, coming up with a work-around should be relatively simple. There's no way to make it easier for people to do this.

What we can do is make it so they don't have to do it as often by fixing Wine. I mean Wine developers can do that. I can't.

Certain things (kernel-space drivers, rootkits..) are outside Wine's scope. Certain kinds of programs will never run. Anything that needs to run anything in kernel-space (if the program doesn't really need it but thinks it does, it might be possible to fake it) will fail because Wine is completely a user-space program. Beginnings of driver support has been added but it can only do things that a user can do. Many kinds of copy protections or software for specialized hardware will never work. This sets a limit on Wine's compatibility that's less than 100% (actually any implementation of win32 will have less than 100% compatibility, including Microsoft's).

Setting up Windows programs isn't easy, even on Windows. I know I wrote about this earlier, but setting up Windows programs properly can be complicated.

The problem here is that so many of these programs have parts that can't be updated, such as the installer on the CD. If bugs exist in those parts, as they have been (Worms World Party can't install from the CD because of this), they can be mistaken for Wine bugs. Wine will never fix this kind of problem.

People are making bad assumptions. People have done the following broken things:

-Changed the C: drive mapping to point to their Windows partition. This is WRONG WRONG WRONG. It will break things horribly.

-Copied the dlls from their Windows partition over their Windows directory in Wine. Also wrong. Why do people keep thinking Wine will somehow function better if it has things from Microsoft? Didn't they learn the last time they tried to use things from Microsoft?

-Run programs that were installed on their Windows partition. That won't work properly because the drive mappings and registry are different. It's like if you dual-booted Windows XP and Vista, installed a program in XP, and than ran it from Vista and expected it to work. Why do people do this? Is it that they don't think of Wine like they would another Windows install or because they think the thing I just said is actually a reasonable thing to do?

People are using outdated (or just plain misleading) guides. There's a lot of misleading literature on Wine, some of it misleading because you used to have to do things that are no longer necessary. This is a problem with computing in general, and we're going to see it happen more on Linux as it becomes more popular.

So how are people supposed to know what guides are misleading? Wellllll, I don't know..

I find that better help tends to exist in communities. Winehq is a good place to go for help with Wine. Communities around a distribution can be ok. Communities around a windows program can be ok. This guy's blog is not (seriously, go here or here instead).

People are using outdated or broken versions of Wine. Distributions are at fault here. Ubuntu Dapper (LTS) comes with the very outdated version 0.9.9. Debian apparently breaks the package into a million pieces and then doesn't install them all when you tell it to install Wine, even though if you want it to work properly you want all of it. This sort of problem is sadly very common, and I wonder how much it's affected other projects.

Wine's sound is a mess. There is active work going on to fix this. Essentially, the most fully-working driver in Wine right now is OSS. For most people, only one program can be using OSS for sound at a time, so they often find that sound doesn't work (Windows programs see this as a computer that lacks a sound card, and some will actually crash in that situation). The default is OSS with full hardware acceleration; the hardware acceleration causes problems too.

The solution: make the ALSA driver good enough that it can be the default. Then make all of them better.

(Update: As of version 0.9.48, ALSA is the default. It still doesn't work quite as well as the OSS driver when OSS works, apparently because of latency introduced by using ALSA.)

People are double-clicking on .exe files instead of running them from the command-line. This is sort of a desktop integration issue, and it's not clear where the responsibility lies (seems to be with package maintainers?). When you double-click an exe file in the file manager on Windows, it sets the working directory to the location of that exe file and runs it. Some programs depend on this.

When you do the same thing on Linux, it sets the working directory to.. well actually it probably ignores it. Anyway it's not the right place. Solution: run things from a terminal, where you can set the working directory with the "cd" command.

Solution if you're not good at terminals: um.. learn? I know this shouldn't be necessary and the very fact that you can double-click the exe files is misleading, but for now it is necessary.

That is, if you want things to work properly.

lawyers are still funny

Sat, 02 Jun 2007 14:38:59 GMT

They've revoked the old key. Here's the new one: 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

laywers are funny ^^

Wed, 02 May 2007 16:51:33 GMT

This string of hex digits is apparently illegal:

09-F9-11-02-9D-74-E3-5B-D8-41-56-C5-63-56-88-C0

It's some sort of key relating to AACS, the copy protection used in Blu-ray and HD-DVD movies. I have no idea what kind of key it is, what it does, or how to use it. It can probably be revoked, meaning it will only be useful for currently-released movies.

So that's not really important.

What's important is that laywers are sending cease and desists over it, which means we can totally annoy them by spreading it.

I'm waiting for someone to write a track with that title so it can show up on last.fm.

I don't know how to use a mop; this bothers me

Sun, 22 Apr 2007 16:55:49 GMT

So there was a puddle of water covering the area outside the shower this morning for reasons unknown. This is now taken care of, apparently not the correct way but at least the puddle isn't there anymore (yay RAs), but it bothers me that I don't know how to handle the situation.

Wine is getting a package manager. Windows should get one too.

Sat, 14 Apr 2007 04:30:32 GMT

I recently discovered a project called Winebot. Winebot is a program that installs/uninstalls windows programs on Wine, handling dependencies, any hacks that might be needed, etc. This is still in the alpha stage so while it can do what I just said, it's not very good at it yet. There have been other projects like this (among them Wine Doors, which I was briefly involved in before I discovered a policy I hated enough to ruin the mood of any future conversation I might have with that project's maintainer), but they've never really worked at getting support (or at least not hatred) from the Wine community. Winebot looks like something Wine developers actually won't hate.

Right, so, Winebot "packages" (and Wine Doors packages; they're trying to be compatible, you see) are tar.bz2 archives renamed to .wdi and containing the following files:
pack.xml - file containing data about the package: name, version, names of the install/uninstall script
scripts/install.something - script that installs the package; this can be one of a number of types
scripts/uninstall.something - script that uninstalls the package

Since I got horribly upset with Wine Doors, the dominant script type seems to have moved from .sh (Bourne shell, a Linux scripting language) to .ahk (AutoHotkey, a Windows scripting language). This is very important.

Wine isn't easy for Linux programs to interact with. Pretty much the only thing a Linux can do with Wine is start a Windows program. Anything else (registry editing, moving around files) must be done manually in the Linux way. Registry editing is particularly difficult. Moving around files also is a bit problematic (but doable--these problems can be fairly easily worked around), since you have to worry about different drive mappings and Windows' case insensitivity (Linux can have a file named CASE and a file named CaSe in the same directory, and when that happens Wine acts very weird).

AutoHotkey is so much better. It can read and write the registry. It can do things with files without worrying about case. It can (!) run an installer and click the buttons so the user doesn't have to do anything, and even that is fairly easy to write. I can actually get things done with it.

Not only is AutoHotkey better than Bourne Shell scripting, it's better than every other way I have seen to make an installer except for two itty bitty problems:
1. You can't package files in it (actually I think I may be wrong about this, but it doesn't matter anyway). This is easily solved with a self-extracting archive or a .wdi package manager.
2. It's not easy to create a nice installer gui thing that can interact with the user and ask for a target directory and has buttons and stuff. Well, it's not that gui in AHK is hard, in fact it's quite easy. It's just that it wasn't designed for installers and installer-like guis involve a lot of code. Do you want to write a lot of code? I sure don't. I want to get things done.

So problem 1 isn't really a problem. Problem 2, however, is also not a problem.

Windows is the only OS that thinks installers have to ask users a bunch of questions before they can install a program. No one else actually does this. On Linux, we tell the package manager we want something, and it installs it. If it needs something else before it can install it, it installs that too. In the rare cases where that's not good enough, we use the command line to tell the program exactly what we want, and then we ignore it until it finishes. Why do installers have to ask us questions?

Well, the first thing they usually ask is whether I want to accept the EULA. Sometimes I even read it. This is, I suppose, mostly unnecessary in Linux because the software is usually free software (though, oddly enough, some free programs still think they have to ask the windows users if they want to agree to the GPL).

Then there's the install directory. How many people actually care about this? How many of the people who do care would settle for specifying something other than "C:\Program Files" that they want to use for every installer? How much time would we save if we never had to click the button to confirm that yes that installation directory is fine and yes I do want you to create it?

Some programs have optional components. That's fine I guess. The Linux way of dealing with this is to make the optional components separate packages.

Installers want to know where to put shortcuts on my Start Menu. This was never a problem on Linux. I have a set of categories (Accessories, Games, Graphics, Internet, Office..) and my program shortcuts go in there. If I really hate the choice, I can move them around. This is no big deal

Oh, and they want my permission to reboot the system. *sigh* Fine, Mr. Installer, I never had to do this for a program anywhere else, but I can see Windows has a special need to interrupt me to finish an installation.

Remember how I said I could use AutoHotkey to run an installer and click through all the buttons so the user doesn't have to do anything? Yeah, Winebot does that. So it turns interactive installers into noninteractive ones.

But we could be making noninteractive installers from the beginning out of AutoHotkey, installers that take developers less time to create and also annoy users less, if only we had a package manager to run things so users don't get confused when they double-click the .exe and nothing happens on the screen. A smart package manager could take care of all those stupid questions installers need to ask by feeding them prepared answers (Well...that doesn't solve rebooting, but it'd be fairly simple to indicate to the package manager that a package expects a reboot after it's installed).

So, basically, I am asking anyone who wants to make a package manager for windows to please do it. Here is a list of programs you could try to make packages for as proof of concept. Use AutoHotkey because it will make things easier. If you can, use the .wdi format. I will love you long time if you make this happen for me.

update: alky is focusing on directx 10 and wants to port vista games to XP

Tue, 06 Mar 2007 19:12:08 GMT

I've got some new information from the mailing list since my last post about alky. Apparently they're working on DirectX 10. This lets them expand their potential userbase to not just Mac/Linux users but Windows XP users as well.

Apparently Alky's STILL Not Dead

Mon, 19 Feb 2007 22:11:58 GMT

DISCLAIMER: I'm basing this on my limited impression of alky from my involvement last Summer when it was open source and from what little I've heard from them since. I might even be making stuff up. Do not take my ranting too seriously.

For those of you who haven't heard of it, Alky is a project designed to convert Windows binaries to Linux and Mac OSX binaries. It started sometime in the summer of 2006 as an open source project. Everything was written to allow for multiple types of target and source binaries.

This probably sounds similar to the Wine project, but it's not the same. Wine works by simulating an entire Windows OS (using no Microsoft code so it's perfectly legal), with everything a program could reasonably expect a Windows machine to have (if you're interested, this includes its own kernel (actually two components: wineserver and the kernel/ntdll libraries), registry, device drivers). The Wine machine also has its own hard drive and Windows directory. Those things (the kernel, the hard disk, the registry..) provide a base on top of which most Windows applications and dlls could run. However, that base isn't enough to run everything; Windows includes some dlls that Wine could run, but it has to provide a replacement so that it can work without any Microsoft code. Wine's dlls build on the lower-level things just like their Windows equivalents. The whole point here is to create a system that is as close as possible to the way Windows works, so programs can't tell the difference.

The Alky approach is different. Alky creates a stand-alone binary that does not depend on a Windows environment, and so it doesn't create one. Alky has no architecture to support multiple programs accessing a registry, passing messages (that's what wineserver is for), and doing other things Windows programs do. Instead, it statically links the program to libraries that are as high-level as possible, simulating Windowsy things as needed. That was a horrible explanation. Let me try to do better with an example.

Suppose we have a game, titled "Revenge of the Pencil Sharpeners". It has an installer, titled SETUP.EXE. The installer installs some files the game needs to support itself, the main program (REVENGE.EXE), and a library it uses (SDL.DLL).

The process of running the game on Linux with Wine (assuming everything works the way it's supposed to) goes something like this:

1. Use Wine to run the installer, SETUP.EXE. Wine loads the installer into memory and runs it. The installer sees a Windows machine with a display and a C: drive with enough space to install itself, so it creates a wizard-like interface to install the program just like it would on Windows. The files go into Wine's C: drive. It writes some entries in Wine's registry for whatever settings the program needs and its uninstaller. It adds menu shortcuts to the start menu, which Wine automatically copies into your applications menu.
2. You find the game's shortcut in your menu, and you click on it to run it. The shortcut invokes wine on the game's main program, REVENGE.EXE. Wine loads REVENGE.EXE into memory. It sees that REVENGE.EXE needs SDL.DLL so it loads that too. The game uses its settings in Wine's registry, it's files on C:, and SDL.DLL. And everything works. Just like on Windows.

The process of running the game on Linux with Alky (assuming everything works the way I think it's supposed to..though I'm not entirely sure..) goes like this:

1. Use Wine to run the installer. That is not a typo. Alky wasn't designed for running installers; it was designed for running games. They figure Wine is good at installers already so why reinvent the wheel. (alternatively, you might use a script specially designed to look in this particular program's installer and extract the files)
2. As I mentioned earlier, the program comes with a library, SDL.DLL. That library builds on other libraries that would normally be found on a Windows machine. That means the Alky developers (because how many normal users would want to do this?) have a choice: implement their own version of SDL.DLL based on Linux libraries, or use the application's version and implement all the Windows libraries it needs. In this case, the Alky developers will choose the first option. It's less work for them because SDL is cross-platform; there's already a Linux version and all they have to do is build a simple wrapper to account for minor differences like the filesystem using forward slashes instead of backward slashes. And their own version of SDL.DLL has to pass through fewer abstractions: in Wine SDL would be implemented based on other Windows libraries which are implemented based on an imitation Windows machine which is implemented based on native libraries. Alky's SDL is just implemented based on native libraries. So step 2 is to implement as much of SDL.DLL as REVENGE.EXE says it needs.
3. This is entirely speculation on my part because I don't know what they actually decided to do about this problem. Here's what I think they'd do based on what I know about the project. The problem is that Alky doesn't have a registry or a C: drive, but any normal Windows program will use both of those. The solution: instead of implementing a REAL registry or C drive, just make an abstraction for something simpler. Implement the registry using a settings file ~/.revenge. Make the C drive mean the same as / (this wouldn't work for programs that expect to be able to do things to c:\windows but I bet it's good enough for REVENGE.EXE).
4. After you have all that stuff figured out, run a converter on REVENGE.EXE with the settings you've decided on. The converter spits out a binary containing everything in REVENGE.EXE and all the libraries it needs to run.
5. Run the binary. Everything that was originally in REVENGE.EXE and all the libraries it needs are loaded into memory. It works, not like on Windows, but as if "Revenge of the Pencil Sharpeners" were actually built to run on Linux. And you didn't even need the source code!

What brought on this post was an announcement that they have a Linux demo out. They're selling it for $50 (the $50 apparently gives you free access to everything they might sell in the future, even though Alky doesn't do much now). See http://www.fallingleafsystems.com/sapling/

I'm not interested enough to spend $50 on it, and they don't sound like they're offering source code, even with no license to distribute (if they did, it might be enough to make my interested). For the actual user, the process I outlined above seems to be something like this:

1. Buy (or obtain for free if you invest the $50 now) an Alky Convertor script.
2. Run the script and let it do its magic.
3. Run the resulting binary.

Gee, $50 for a black box that doesn't currently do anything but convert a demo that runs on Wine (and maybe more black boxes later for actual games I probably won't play). No thanks.

how to fix Linux after Windows has taken over your boot process

Thu, 01 Feb 2007 20:03:55 GMT

This is a common problem that a quick Google search didn't find me a good guide for, so I'm just going to write something up. Most modern installs of Linux use the GRUB bootloader, which can create a nice menu allowing you to choose to start any operating system installed on the computer. It's very convenient for dual booting because GRUB can start Windows if it has been installed.

You can have many operating systems installed on one hard drive, but only one of them can be installed on the Master Boot Record. This isn't a problem if you use GRUB because it creates that nice menu that lets you start any of them.

Unfortunately, if Windows somehow takes over your MBR after Linux has been installed, there's no way to boot Linux (well, maybe there is, but it sure isn't easy). This would be easy to fix from within Linux; use the grub-install command to install grub to the MBR again, but for that to work you'll have to somehow get into the Linux environment that's on your computer. Fortunately, you can do this from a livecd.

Note that any livecd will probably work; it doesn't have to be the one supplied by your distro. If you don't have a livecd (and don't need a gui), you can use Gentoo's minimal CD, which is relatively small (about 125 MB apparently) and will dump you in a command-line environment. Or if you like to have guis you can use ubuntu's livecd, which is much bigger but may make you more comfortable.

Once you've started Linux using your livecd, you need to make yourself root. Gentoo's livecd will do this automatically. On Ubuntu's livecd, start a terminal and type "sudo -s".

Now you need to recreate your installed version of Linux within the livecd version. Start by making a /mnt directory where you can set up the file-system (type "mkdir /mnt"). If you remember how you had your partitions set up, this will be handy right about now; mount those and skip down to "Now that your disks are mounted". I'm going to assume for now that you do not (or you don't know about mounting).

The most important thing is to find your root (/) partition, which you can do through trial and error. Type "fdisk -l" to get a list of all the partitions that are on your computer (possibly including those on disks you have inserted).

On my computer, the section dedicated to my hard drive looks like this:

Disk /dev/hdb: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1   *           1        4342    34877083+   c  W95 FAT32 (LBA)
/dev/hdb2            4865       14593    78148192+   f  W95 Ext'd (LBA)
/dev/hdb3            4343        4864     4192965   83  Linux
/dev/hdb5            4865        4873       72261    b  W95 FAT32
/dev/hdb6   *        4874        5800     7446096   83  Linux
/dev/hdb7            5801        6052     2024158+  82  Linux swap / Solaris
/dev/hdb8            6053       14593    68605551   83  Linux

Partition table entries are not in disk order

I know I installed Linux on that drive, so the root partition must be one of those devices. I know it can't be any that say "W95 FAT32", "W95 Extd", or "Linux swap" so I will start by trying /dev/hdb3.

To mount it, I'll type "mount -r /dev/hdb3 /mnt". /mnt will now contain what that drive contains.

If it's the root of a Linux install, it will contain a file called /etc/fstab. To check, type "ls /mnt/etc/fstab".

If you see this:

root@ubuntu:~# ls /mnt/etc/fstab
ls: /mnt/etc/fstab: No such file or directory

that means it's the wrong one. You will have to unmount it (type "umount /mnt") and try another one.

If you see this:

root@ubuntu:~# ls /mnt/etc/fstab
/mnt/etc/fstab

then the device you've chosen is the root of a Linux install (I'm assuming you only have one), and you can move on.

Because I had you mount the filesystem read-only (that's what -r does), you'll have to remount it so you can read and write. To do that, type "mount -o remount -rw /mnt".

To find out what other filesystems, if any, you need to mount for your environment, look at /mnt/etc/fstab (type "cat /mnt/etc/fstab").

Mine looks like this:

# /etc/fstab: static file system information.
#
#                
proc            /proc           proc    defaults        0       0
/dev/hdb6       /               ext3    defaults,errors=remount-ro,user_xattr 0       1
/dev/hdb8       /home           ext3    defaults,user_xattr        0       2
/dev/hdb7       none            swap    sw              0       0

/dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/hdd        /media/cdrom1   udf,iso9660 user,noauto     0       0
/dev/fd/0       /media/floppy0  auto    rw,user,noauto  0       0
/dev/sda1       /media/usbdisk  vfat    rw,user,exec,auto,uid=meh         0       0
/dev/sdb1       /media/usbdisk  vfat    rw,user,exec,auto,uid=meh         0       0

If the file system isn't a partiton (like the one where the device is listed as "proc"), you can ignore it. If the mount point is "none" or it starts with "/media", you can ignore that too. You've already mounted "/". In my case, the only line that matters is the one that starts with "/dev/hdb8". I would have to type "mount /dev/hdb8 /mnt/home" to mount it (I have to add /mnt before the mount point because that's where I'm building the filesystem).

Now that your disks are mounted, you'll have to mount a few more things that aren't disks (/dev and /proc), like so:

root@ubuntu:~# mount -t proc none /mnt/proc
root@ubuntu:~# mount -o bind /dev /mnt/dev

Now you can switch to the version of Linux that's on your hard drive. To do this, type "chroot /mnt /bin/bash".

If that worked, /mnt has magically become / in your terminal. This isn't exactly the same as if you had booted to Linux, but it's good enough to repair your install.

Now here's the easy part: run grub-install on your hard drive. If a partition on your hard drive was called something like /dev/hda1, your hard drive is /dev/hda. My partitions started with /dev/hdb, so I'd type "grub-install /dev/hdb".

for the record, this is what I think about God

Sun, 19 Nov 2006 10:10:01 GMT

I've been looking for a name for what I think about God. Theism doesn't quite cover it. Wikipedia has an article that describes something called eutheism, but that's not quite it either.

I'm having trouble describing exactly what it is I think, but I seem to do ok if I start with how I make moral judgements.

I don't really have a system of beliefs about morality. There are just certain times when I can look at something and know that it's good or that there's something terribly wrong with it.

For instance, I never really had a position on abortion until my sister became pregnant. For the record, she was not considering an abortion to my knowledge, nor do I know of any reason that she would. Her son, my nephew, has been born and is, to the best of my knowledge, now healthy. But when she was pregnant, I was able to look at abortion and know that there was something terribly wrong with it. I couldn't do that before. Does this mean it should be illegal, or that it's never the best option available? I don't know. I just know that there's something terribly wrong with it.

It's not limited to moral judgements. I can sometimes do the same thing with works of art (for instance, this track I'm listening to right now, "The Accident" by Squonk Opera, is good; I don't know why, I just feel it).

Admittedly, this isn't useful in a lot of situations. When thinking about nearly anything related to sexuality, I get nothing. I don't know if it's good. I don't know if there's something wrong with it. I know there's something wrong with war, but what about when war is used to solve another problem? I don't think that whatever good comes out of it will ever be worth it. But I can't be as sure of that as I am that there's something wrong with war.

Now, where this starts to involve God is when I ask why it is that I'm able to do this. That's not a difficult question to answer technically. The simplest explanation is that my brain is wired for it, much like it is wired to experience emotions like anger and sadness. Occam's razor tells me that I should accept that one.

But in that case, can the things I know this way really be applied to other people? If it's just a function of the way my brain happens to work then, well, it's just my opinion. Others may think differently. It's no different from the fact that I happen to dislike mayonnaise.

No. Fire alarms go off in my head when I start to think this way. I know there's something wrong with that line of thought the same way I know there's something wrong with abortion. And I trust that feeling more than I trust Occam's razor or any reasoning that will be presented to me. You cannot argue this point with me. It is not just my opinion, it is the Truth.

And that is, I think, my religion. I believe in this feeling that I have about certain things, that they are good or that they are seriously flawed. I use God as a catch-all term to describe the feeling, the reason for it, and good. I don't have feelings about whether God is omniscient or omnipotent or whether he created the universe the same way that I feel good and serious flawedness (the term I keep thinking about replacing with evil, but I'm not sure evil is exactly what I mean). I have an opinion about these things, but that's not the same. I think maybe in the future, I'll need to keep my opinions separate from my religion, as they have a tendency to get confused.

I believe that goodness exists and is absolute and knowable. That is the most important thing in the world to me.

"How to steal an election by hacking the vote"

Sat, 28 Oct 2006 23:55:12 GMT

I don't normally make posts just to link to something, and I realize the number of people who are likely to read such a post is small, but damnit this is serious.

http://arstechnica.com/articles/culture/evoting.ars

Re: Reconciling Microsoft and the open-source movement

Thu, 14 Sep 2006 16:05:46 GMT

Neil McAllister has recently written an article titled "Reconciling Microsoft and the open-source movement". In this article, Neil has not said a single thing that matters. Not one thing.

Yes, many supporters of open-source do have a "fortress mentality". Many believe that Microsoft is evil. I've heard these people in mailing lists. I'm sometimes a little embarrassed by them.

"It’s time for open-source advocates to set aside their pride, recognise their place in the larger software market and start working to build bridges, rather than fortresses."

This sounds like a wonderful idea, but most of the bridges that matter so far have been built by people on the open-source side, sometimes the very same people with this so-called "fortress mentality", and most of the fortresses that matter have been built by proprietary companies like Microsoft.

Microsoft has not taken the time to support any Linux filesystems. Why should they? It is not in their best interest to make switching from Windows to Linux easier. Linux, however, appears to want to support every filesystem possible, including ntfs. It does have a somewhat working driver (it definitely at least reads the system correctly), but it's not as if they've had any help from Microsoft. An open-source driver also exists for reading ext3 on Windows.

The standard open-source audio format is ogg vorbis. Microsoft has made no attempt to support it, even though they have the specs and a reference implementation that already builds on windows and has a BSD license. So the only thing they'd be required to do to play the files is write some glue for Windows Media Player and *ahem* set aside their pride and acknowledge xiph.org in compliance with the BSD license, which they've apparently already done for other projects in the past. Sure, there are plugins available to do it, but why doesn't WMP just support it? Open source has done everything is possibly can to make it easy for WMP to play ogg vorbis files, but Microsoft has to take the final step and actually do it.

It's not open source that needs to change here. In spite of the rhetoric, open source projects have been doing more than one could reasonably ask in the name of compatibility with other systems, even proprietary ones. Individuals in the open source movement may bash Microsoft. I've just bashed Microsoft myself. Most of us probably think that Microsoft's software is crap compared to what we're using now; why else would we be using it? Some people think that porting open source software to windows is a bad idea (I'm not among them), but these people do not matter. If people with the technical skill want to port things to Windows, they can do it, and often they have.

By its very nature open source encourages compatibility, as it always has, in spite of anything its supporters might think about the things it may become compatible with. When Microsoft decides they really want compabitility with open source technologies, they can have it, and no one in the open source movement can stop them.

Oh my god, it's 1992 again

Fri, 04 Mar 2005 06:40:06 GMT

I want to build a window manager. So I start reading related standards, in order to figure out what the hell a window manager is supposed to do. According to freedesktop.org, I'm supposed to comply with something called the ICCCM 2.0.

Among the Simply Amazing features this standard offers:
"The icon_pixmap field may specify a pixmap to be used as an icon. This pixmap should be:
-One of the sizes specified [blah blah blah]
-1-bit deep. The window manager will select, through the default database, suitable background (for the 0 bits) and foreground (for the 1 bits) colors. These defaults can, of course, specify different colors for the icons of different colors."
If you counted 10 (known to people who aren't using binary for the sole purpose of being annoying as "two"), you are incorrect. In fact, one can add an alpha mask to this (also 1-bit), giving you a total of 3 colors.

Or maybe transparent doesn't count.

Whatever. It does go on to define a window that can be used as an icon. In a later section. Maybe it works; maybe it doesn't.

I've also been given this wonderful piece of advice:
"Most, but not all, window managers will support icon windows. Those that do not are likely to have a user interface in which small windows that behave like icons are completely inappropriate. Clients should not attempt to remedy the omission by working around it."

Of course this is true (so I'll have to make sure my window manager does this), and not only for those of us on some variant of Unix. The rest of the world still uses Windows 3.11, MacOS, or AmigaOS.

Disclaimer: I've done absolutely no fact checking. None.

Are you asking for a CHALLENGE?

Mon, 21 Feb 2005 17:22:53 GMT

I hate this. Yet I'm clearly choosing this. Maybe it's the sort of choice where your life will suck otherwise, but I'm choosing this. Because no other choice is acceptable.

This is the sort of thing that happens to people in well-written books. It doesn't happen to REAL people.

I was in the "Data Structure and Algorithms" lecture this morning playing solitaire. Canfield (aka Demon) solitaire to be exact, not that it's important. So the instructor is talking about overloading the assignment (=) operator for a class using dynamically allocated memory, and he mentions the necessity of checking the identity of the object being assigned against the object being assigned to. If they are equal, the algorithm he uses breaks down (because the algorithm always deallocates the memory in use by the thing to be assigned a new value first--if the identity is the same, it will proceed to copy from memory that has been lost).

So he asks me (specifically) why this is necessary. I answer. He rejects my answer, waits, and asks someone else, who says essentially the same thing I said. He then asks me if I get it. Of course, as I understand it, that was what I said, so that is my answer.

Someone else who was there recounted the events and had basically the same impression, except that he had actually looked at the algorithm and noticed (as I probably would not have even if I had looked), that he was checking the values of the objects for equality, not the identity. Yes, if the identity is the same, the value must be the same, but this is different (and slower) from the way it was explained.

So. The important detail that's missing from this story is this: why did he specifically ask me this question? I'm not sure how many names he knows..but he hasn't been known to just ask people questions in the past. I think it probably stems from the fact that I was playing solitaire (Canfield, but he didn't know that) and not looking at his slides. Given that, possible motivations:
-He is genuinely concerned that I, personally, may not understand the concept involved.
-He is insulted that I'm not looking at his slides and generally not paying attention to the lecture.
-He's trying to prove that it is necessary for me to not be doing anything else during the lectures.

Let's get the genuine concern out of the way first. If it's something that only involves me, why can't he say it to me personally? If an instructor feels that a student does not understand something, common sense dictates that the middle of a lecture is not the time to point this out, as that would be cruel.

He may very well be insulted. Perhaps I should send a personal query to him asking if his feelings were hurt. But perhaps not. I mean, this man is an adult. By some theories, I'm an adult, but I don't feel like anything has actually changed since my not being an adult. In any case, we have a very specific professional relationship that says nothing about this.

That leaves him trying to prove that it is necessary for me to devote my full attention to the lecture. This just isn't true. Even if it is true, it's not his responsibility. The responsibility for picking up the material is mine. The instructor is there to give me the requirements of the course, to provide tools to help me to do this (including lectures), and to evaluate to what extent I meet those requirements. This is college; if I don't need to attend classes, I shouldn't be expected to attend classes.

So I could just not attend the lectures. Naturally, there would be quizzes, and these would affect my grade. More importantly, this is a coward's way out, and I do think it's helpful to attend lectures, even though I don't need to always devote my full attention to them.

I could also refrain from playing solitaire during the lecture. At the moment, no one has expressed any problem with me doing so (and if attending lectures should be optional, as is my claim, the appearance of attention should also be optional).

That leaves me with playing solitaire for every remaining lecture, hoping this does not continue, but ready if it does.

Linux...

Sat, 04 Dec 2004 22:57:14 GMT

A couple of weeks ago, I switched to Linux. I'd set up my computer (partitioned) with this in mind. I made the mistake of using Gentoo Linux, which is probably the most difficult distribution to set up.

So anyway, I'm now running GNOME under Gentoo Linux. I don't feel like talking about how I got it set up, but I'd like to say something about compatibility, and about windows.

Reasons to use Linux:

- openness - Ideally, a Linux system is completely transparent. This makes it easy to implement things that Linux programs need in other architectures. The Windows API, however, is not open at all. Windows programs simply assume they have everything that's in a Windows 98 SE (in most cases, I'd say this is where they draw the line) insllation, but there isn't any official complete listing of what those things are and how, exactly, they should behave. (Also, Microsoft has to be VERY careful about what they remove or they sacrifice compatibility). In contrast, it's very clear what components Linux programs rely on because one can never be sure that they will always be on any Linux system.

- open source - The ability of end-users to compile things from the source allows a lot of packages to run on various architectures on top of unix-like systems. It also gives people the ability to make modifications for compatibility with new systems. Open source means that no one can control software--the destiny of the software is determined by anyone who has the ability to modify it.

- attitude - Linux software tends to be written with the mindset that the user should be able to control it. As a result, the DVD player software I use gives me an option to set the region of the player (I don't remember ever seeing that before....but if everything we used was built with that kind of thinking, we'd never have to put up with the whole "DVD region" business). I can change my MAC address by adding one line to my network configuration file. Now that I have some experience with the system, it's easy. No other mainstream OS (read: not mac os or windows) makes this so easy (though to be fair, no normal person would want to do this, and even in this case it was an odd circumstance).

- security - Unlike Windows, Linux was actually designed to be run with a normal user who doesn't have access to the whole computer (later versions of Windows allow this, but Windows programs tend to expect to have this access and fail if they don't have it). This means that if (god forbid) some malicious code manages to run on my computer, it can only do what I have permission to do. This can still be a lot of damage, but it isn't enough for the virus to actually install itself on the computer, meaning that it cannot affect my ability to log on as the root user (read: administrator) or do anything I could normally do as that user. So while data loss is possible, and it could mess up your normal user, it will never be necessary to reinstall anything or fix any core packages as a result of malicious code. Nor will one person's big mistake (provided he doesn't make it while logged in as root) affect other users.

- screensavers - Not a major issue, I know, but xscreensaver is so much better than the stuff that comes with Windows.

- no gui required - Lots of things that you'd actually want to do can be done without a gui: you can play games, browse the web, check email, and sign on to IM services all on a text-only multi-tasking environment.

Reasons to use Windows:

- running windows programs - There are a lot of good programs designed for Windows. Sure, there's free Linux software for most of the things you'd want to do, but not for everything. Many of these programs will run on Linux using WINE, but this isn't a reliable solution (yet). I have a lot of games that still won't run on Linux. I am confident they will run some day (and that I'll have the skills to make it happen some day), but for now I have to run Windows in some form if I want to play them. I don't.

- device drivers - A lot of hardware companies don't provide drivers for Linux. Sometimes it's possible to make the hardware to work some other way, but it's much more likely to work on Windows (unless you thought of this before you purchased it).

- inertia - Computers tend to come with Windows pre-installed, so it's much easier to just stay with that than to try to switch to Linux and get a refund for Windows.

- maintenance - It's always necessary (no matter what anyone tells you) to have someone who knows what he/she's doing to maintain your computer. Someone who knew what he was doing in Windows won't necessarily understand a Unix-like system. It helps, but this is very different.

I don't know of any reasons that have anything to do with Windows actually being better.

It's all been done before

Thu, 07 Oct 2004 20:34:40 GMT

The idea I posted previously of networking objects has been done before. It hasn't been done in a way that takes advantage of Python's dynamic typing (types must be specified ahead of time, but I probably would have had to require a similar level of validation), but it has been done. It's called CORBA, and the implementation for Python is called, for reasons I cannot begin to fathom, Fnorb. Oh, and it requires a c++ preprocessor for the part where we define the types. I'm not writing anything in c++, but apparently they use it for something. At least end-users don't need it..

I've known this for a while, but my idea of writing a program to play Fluxx has been done before. I've just recieved some new information about this that I thought I'd share. The program was known as Shifty, and it ran on a Palm Pilot (apparently Player vs. Computer only). The author changed its name to MicroFluxx after it became a legitimate (authorized by Looney Labs) venture. The author has now taken down the program and no longer supports it. It was released under the GPL, and someone was nice enough to put up an old version of the source for download. I can't use the source for anything, but I have learned a few things about this program. It's for Fluxx version 2 so the author never had to worry about X=X+1. The deck is very much locked in; there's no way to add or remove cards without editing the code recompiling. It does have AI (or course), something I had thought would be very difficult to implement. So I stand corrected. It would be very difficult to build AI that's any good at the game, especially when you throw in the possibility of nonstandard cards/rulesets.

About a week ago, I sent an email to the Arcade list with the current working version of ObjectFluxx attached and announcing that I'd like to release it. The email was too big and so it didn't go through. I was told that it would either be rejected or approved by a moderator. If it's rejected, I should get another email about it. If it goes through, I should get it back because I'm subscribed to that list. I haven't gotten any response yet. So I sent another email yesterday without the program attached. Nothing there either, but I know it went through because I got my email back through the list. To be fair, people haven't had much time to respond to that.

Andrew Taylor has created a program for playing Minesweeper Flags offline. Apparently (I can't seem to find a link with an explanation for this), the object of this game is to identify as many mines as possible. When you click a square that is not a mine, your turn ends and that square is cleared (as well as all surrounding squares if there are no mines next to it). The program also features hexagonal and tetris (the board "falls" and you have to flag the mines before it hits the bottom of the screen) modes.

My absentee ballot hasn't arrived yet. I'm starting to worry.