Wrapping up another week at the beach. I'm feeling nicely relaxed, did basically nothing most of the week. With 11 people here it was a bit of a croud, but I'm happy each of them came, so no complaints. This trip was over the 4th so a high point was watching Ocracoke's fireworks display in one direction and Hatteras's up the beach in the other.

Ocracode for this trip:

OBX1.1 P11 L7 SB3d++++b---c+ U1(the point,Kai2.5) T1f3b0 R0d++ Bb-m+n+
F++u+ SC++s---g7 H++f2i3 V++s+++m5 E+++r++++

Driving to the beach, we saw these signs throughout the Carolina flatlands, with no explanation of what "OLF" was. Speculation ran wild. It seemed to be associated with buildings that might have something to do with Labour/Farming, but what was the "O" for. Maybe it was something else. An OverLand Ferry? Etc.

Turns out it's an Outlying Landing Field.

Youtube video.

I got a SIO2PC cable for my atari, hooked it up to a linux box, and used the atarisio tools to rip a few of my old BASIC disks. Now I can load them in the atari800 emulator, and will hopefully never lose this early code -- cuz it's in git now.

The first disk I rescued ("finished programs disk 1") has a nice little menu on it with lots of games and stuff I'd put together.

I've always been proud of the "vidio" game, which is the first game shown above. It'd give Pong a run for its money in simplicity, and has gameplay I still enjoy (for up to 5 minutes at a time). You're the green dot, which is flying from left to right. Each time it reaches the right side of the screen, it wraps back to the left -- but leaves a blue wall behind. Crash into the wall and you lose a life. Sometimes other dots appear that you can pick up to get new lives.

This sounds easy, but it's not, mostly because the Atari joystick (or my code for reading it) is not very precise, so it's hard to line up to exactly the right place on the screen to go through a small hole in the wall.

In contrast to that piece on innovation, the "jump" game is a pretty generic platformer, jump over the water and shoot the enemy that's crawling along the ceiling. It's also a bit buggy.

I took a look at the code, but the bug on line 200 isn't very obvious, whatever it is. This is how everyone's old code looks to them after 20 years ... right?

Update: Some more games I found..

My version of Tetris for the Atari. It looks a lot better on a real TV tube. Two fun things in writing this were that I couldn't figure out how to program it to rotate the blocks on the fly -- so I just wrote out data with every possible rotation for every block. Also, Atari BASIC lacks arrays, so it uses strings for storing the game state.

(Colors are ok in 1st screenshot, but messed up in second.)

Fatso's adventure had the best graphics I did on the Atari. It remapped parts of the the character set and used ATASCII characters as sprites. Ok, it's kind of a Lode Runner clone, but only the kind you write after having seen Lode Runner for 2 minutes. Looks kinda like it, but I don't think Lode Runner had spiders that dropped exploding eggs that broke all the rungs in the ladders..

Update 2:

Disk images are nice, but regular files are nicer. I was able to explode files out of the disk images only with difficulty. I ended up using wine to run a windows program called Total Commander. It has a plugin that allows .atr disk images to be unpacked.

To view the BASIC files, they have to be detokenized. I found a perl script to do that, that can be used on the fly of anything suspected of being a BASIC program. All the stuff is in my subversion repository.

I've been playing some computer games this week, which I don't often do. I finally tried a modern version of this Wesnoth game that everyone in Debian was playing a while ago, and have been enjoying working through the stories in it. I played glest for a few hours, and really enjoyed the 3d graphics, especially when it rained. I'm no good at real time strategy games though, and ordering units around contantly becomes wearisome. Globulation 2 might partially manage to avoid that problem, I'll have to try it a bit more sometime.

Transcend is an amazing thing. After finishing a level, I found myself avoiding going on to the next level for a long time so I could spend time messing around with the thing I constructed while playing the game -- and wished there was a way to save my creation. The graphics are reminiscent of kalidoscopes and flowers. It subverts tradition, it has the trappings of a spacewar descendent, but instead of Star Control, the game turns out to be about music growing. Like tetris, it's abstract enough that I can zone out while playing it and get into a different mental state; and I can even pick which kind by making different kinds of music as I play. Wow, wow, wow.

(Or the unfortunate story of why I am not yet participating in the Debian games or perl teams.)

I'm a big fan of both the Debian games and perl teams. The games team keeps finding new and interesting games and flowing them into Debian. The perl team is responsible for a rather amazing quantity of perl modules. Since I maintain both some games and some perl modules, I've looked at participating in both teams from time to time. I think it's odd that the reason I haven't been able to do so in both cases comes down to something as basic as how they use their subversion repositories.

In the case of the perl team, they have a fairly standard use of subversion, as explained in their guide. The problem is repository layout. They chose to use the "package/{trunk,tags,branches}" layout rather than the "{trunk,tags,branches}/package" layout. This means that it's not easy to check out the source for every package in the repo all at once.

Having all the sources checked out is a prerequisite for many kinds of work that span all packages. In my work on the d-i packages, which are in a repository using the latter structure, I often grep all the packages for a problem, and fix the problem in every package. To manage this with the debian-perl repo, I'd either have to check out the whole thing, with who knows how many gigabytes of tags, or I'd have to construct and maintain an svn:externals list that checked out the trunk of every package.

(Open offer to the perl team: I'd be happy to reorganise your repo for you.)

The games team uses the "{trunk,tags,branches}/package" repo layout, which is nice. But they have a policy of not keeping all upstream files in subversion at all. They prefer to only keep files that are patched in subversion, to save space. That looks on the surface to be a nice space optimisation, especially for space-hungry game data, but from what I tell, what it saves in space, it loses in complexity and maintainer time. And my time is much more valuable than alioth's disk space.

It's also very debatable how much space this saves at all for games. I keep uqm and all its data files in one subversion repo. I have 4 years of history of all of upstream's changes to the files in there, and it takes 165 mb of data. Which sounds like a lot, but the files in trunk alone take 170 mb to check out (not counting .svn directories)! And the games team is also storing upstream tarballs in a directory on alioth. One tarball per release, often multiple releases per game, 2.0 gb of tarballs in all. Would it really use much more space in svn? Even if it used 10x the space somehow, is 20 gb even worth worrying about? I think not.

(Open offer to the games team: I'd happily do the grunt work of checking in upstream sources for all the games in your repo.)

(Update: I realized after posting this that while the space gains on alioth might be illusory, there is certianly a space gain for people checking the whole repo out. What's really needed is a way to keep all the upstream sources in svn, but check them out only when wanted, and check out all the debian directories for cross-game work. Hmm..)

I also checked out one other big package repo, collab-maint. The policy for collab-maint's repo uses the same structure as the perl team's repo. However, I doubt I'd ever want to check out all of collab-maint or do group maintenance across it, so that's not a big deal. The documentation also recommends not storing upstream sources in svn, although I've found a lot of packages in the repo that do. I could probably dump in ~100 mb of subversion history for 50-odd packages without anyone caring ... right?

It's interesting that all three of these big subversion repos have their own custom policies for how to use their repo. Having different policies for each repo results in more complexity and a higher learning curve. I wager that 99% of all the packages in these repos are pretty stock in their packaging and can be pretty easily understood and worked with by most Debian maintainers. We've have de-facto standards and policies that they all use. Until you get down to the repos, which, despite using subversion each seem to need to go their own way for some reason.

Spurred by Anibal creating a udeb for rdate, I've been working on adding NTP support to d-i. As usual when working with clock and time related stuff, it's been a bit of a PITA. And figuring out what order d-i should do the various needed things has been tricky.

Today was HP day again. Kinda like Christmas, HP day is when I wake up to some new HP hardware in a box under the mailbox on the porch. For some reason, HP keeps sending me hardware, and this time they shipped me a HP t5725.

It's kinda funny what's called a "thin client" these days. This box has 512 mb of flash memory, no moving parts, and is silent. Other than that it's a fullfledged desktop machine in a very nice smallish package.

The OS is a very lightly modified Debian sarge. They did a good job at adding their tweaks without getting in the way of Debian. I was able to install whatever additional packages I wanted on the hundred+ megabytes of free space. Most users will probably be perfectly happy with the preinstalled system, you can surf the web, etc.

This was one of the few preinstalled systems that I've actually used for more than 10 minutes without wanting to blow it away with my own custom install. If felt sorta silly to do so, but I'm installing testing on it right now via netboot.

... That went fine, no issues whatsoever. Though on a system with this size disk, tasks are useless and every package must be hand-picked right down to the xorg video driver packages.

So it really is a thin client for me, NFS root is a good way to go, and means that I have a machine on my desk that I can use as a workstation, and easily reboot to use as a d-i and rootsync testbed, without worrying about preserving the contents of its disk.

Sometimes the mad libs way we have software fill in the blanks and make a sentence can be unintentionally interesting. Like this old but good one, that sadly doesn't work with GNU make:

% make war
Don't know how to make war. Stop. 

I was pleased when ikiwiki made up this sentence when editing a discussion page.

Creating discussion sounds like a fine goal for a wiki.

But I was startled to see this in Gnome, after I picked "Windows" from the "Preferences" menu:

Yipes!

Remember when sponsoring packages was implemented in Debian? Imagine if we had felt the need to vote on whether we were allowed to do that. Instead of just doing it.

I'll bet that some people would have argued against, citing reasons such as:

It appears to me that the sponsorship as sketched in the GR is mainly meant to let NMs upload earlier, i.e. it tries to fix the fact that front-desk or DAM approval take too long. I think the fix for that is just to find someone besides Joerg to also read the AM reports. Sponsees as in the GR are a workaround, not a solution.

or:

But the GR micro-manages too much and on the other hand doesn’t make the current NM process any easier for Sponsees than for any non-Sponsee applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer Sponsee status over DD status.

What is the difference between a Sponsee and a Debian Developer? Who is interested in becoming a Sponsee and not a Debian Developer and why? Will this Sponsee class really improve the situation for New Maintainers?

or:

I suppose most of our New Maintainers will aim to become a Sponsee just to bridge the time until they’re full Debian Developers. And I predict that this is also the major target audience for this new Sponsee class. Some people said on -vote that there are people actually interested in becoming a Sponsee and not a Debian Developer. Personally I find their reasons questionable, but after all I suppose there won’t be many people going this route. On the other side, I don’t see how this new class enhances the situation for the New Maintainers. Now they not only wait for the Application Manager, Front Desk and Debian Account Managers — No, now they will also search for someone who sponsors them.

So my question is: If this General Resolution mainly helps New Maintainers, why must it be so complicated? Why another class of contributers, all those complicated rules to set it up and this additional layer of bureaucracy?

or:

If you think the NM process is taking too long, then it's probably better to help out there rather than to try to create a system to bypass it in this way.

But instead, we somehow made the enormous change that sponsorship entailed in how Debian works, without voting on it. Make no mistake, it was a big change on both a technical as well as a social level.

Now IMHO, the DM proposal is just fixing a bug in the current sponsorship process. The interesting thing to consider is, if this vote fails, how can the bug be fixed without another vote? I personally believe that any DD has the power to fix this without dragging the project through a vote. They may put their status as developer at stake in fixing it, if they take what seems like the obvious approach, but if one feels that this bug in sponsorship is a bad enough bug and is hurting Debian enough, that might be worth it.

discussion

Even if I did nothing else this summer, I feel like I could look back on just today and feel that I'd a long summer full of lots of summer fun. Maybe that's how memory works for me, suddenly I'm fully aware and stashing away every instant, as we jounce down Anna's very rutted and muddy road, in a trailer pulled by a four-wheeler. Later, taking a swim in the creek, I find that Lucy loves to chase splashes as they arc through the air, and try to catch them in her mouth. I get the dog to bound higher and higher out of the water, and then dissolve in a puddle of hilarity. Then I find out she also likes to chase gravel thrown into the creek. We do this for an hour or so, and I find a very strangly shaped rock, that turns out to have metal in it. There was also grilling of every vegetable that could be pulled out of the garden, and lots of hard work loading many loads of cinderblocks into that trailer.

Now I'm in my tent enjoying the rain and adding alsa support to hotkeys.