Search Results: "ron"

26 July 2007

Sven Mueller: Re: voting on sponsorship

Joey, I see a huge difference between voting on the current DM proposal and your virtual (sorry, I can’t remember a better word for it) voting on sponsoring uploads. Debian Developers were always allowed to upload any package they saw as fitting into Debian (though there were no guarantees for these packages to actually being included). Also, NMUs are OK if the maintainer agreed. So all they (seemingly) did was putting a different maintainer address into the control file. However, at least in theory, the sponsors were still responsible for their upload if it turned out fishy. The DM proposal (don’t get me wrong there, I generally support the idea, I just don’t like the way it is implemented in the proposal) is shifting this responsibility from the sponsor onto the shoulders of the DM, which is a good thing. However I think it doubles some of the work the NM queue already needs done, so my proposal would be not to have it as a completely seperate path for a contributor, but instead see it integrated into the NM process. Wether it would mean adding a new maintainer to the DM keyring after he had an advocate (which is pretty near to the current proposal) or after an AM was assigned and checked some basic things (which I would prefer) doesn’t make a lot of difference to me.

Joey Hess: voting on sponsorship

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.

Wouter Verhelst: The "Debian Maintainers" GR

I had mixed feelings about the Debian Maintainers GR. It perhaps somewhat seemed like a remotely reasonable thing to do given enough beer, but it sure as hell also felt like a gross hack and workaround. Seeing people such as Christoph Berg (who's on the NM Front Desk) speak out against it, and reading arguments from other people who are opposed on Planet Debian, has helped me clear up my mind. I don't think it's proper to do this, and I'll vote against it. That's not to say I'll oppose every similar proposal; it's just that I don't think this one should be implemented. 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. And yes, I'm doing my part.

John Goerzen: OSCon and Portland Photos

I've taken my camera around OSCon and Portland a bit. Here are a few photos that I've taken so far.

At OSCon Itself

(click here to see all)

img_3165

Overflow from breakfast. Most tables had powerestrips and laptops on them.

img_3204

Debian booth at the expo hall. And the only one with beanbags. Sign reads "The developer is in."

img_3166

Filing in for the keynotes. Everyone seemed to want a seat either at the very front or very back.

img_3177

Simon Peyton-Jones explaining how locks with traditional threading can be improved upon with transactional memory.

img_3202

Run for your life! The bell will attack at any moment!

I didn't hear it ring all week.

Around Portland

(click here to see all)

img_3127

The Japanese Gardens were beautiful and tranquil. Jacob actually feel asleep while being rolled around on his stroller.

img_3145

For some reason, this one reminds me of the Jedi Academy in one of the Star Wars video games.

img_3118

One of the many bridges in Portland.

img_3164

Terah's favorite find: Sweet Masterpiece Chocolate and Coffe.

We went there after the Blossoming Lotus Cafe, which was an interesting experience but not quite as good as I had hoped.

Bastian Venthur: On Debian Maintainers

When voting on the current Debian Maintainers General Resolution, I think it’s worth to think about the following questions: What is the difference between a Debian Maintainer and a Debian Developer? Who is interested in becoming a Debian Maintainer and not a Debian Developer and why? Will this Debian Maintainer class really improve the situation for New Maintainers? I suppose most of our New Maintainers will aim to become a Debian Maintainer 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 Debian Maintainers class. Some people said on -vote that there are people actually interested in becoming a Debian Maintainer 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 advocates them to become a Debian Maintainer and have to wait for their key being added to the Debian Maintainers keyring. 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? Why don’t we aim for something simple, like improving our New Maintainer process. I would rather see some of those Debian Maintainer rights granted to New Maintainers after a certain point in their New Maintainer career, but not in this complicated and overengineered way the Debian Maintainer class proposes.

Christoph Berg: The DM GR

I haven't said anything in the DM threads yet because I still don't know which actual problem the introduction of DMs is trying to solve. IMHO the current process with sponsors reviewing and uploading packages has proven to work nicely, i.e. the amount of broken packages uploaded is not too high. Most of the perceived problems with this process stem from the fact that most of the packages offered on debian-mentors or #debian-mentors are initially crap and need lots of review cycles. Once people produce good packages asking the last sponsor for another upload should work. (And at that point NM will be a breeze.) Particularly I don't like the fact that the "initial policy for an individual to be included in the keyring" does not include any check of any technical or non-technical skills besides having a gpg key and be able to tick 3 checkboxes. I fear this will lead to people blacklisting "DM" packages because they don't want low-quality packages on their machines. At the same time, the rest of the GR text is micro-managing every other detail of the process in a way that doesn't leave much room for practical implementation decisions. It appears to me that the DM concept 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. DMs as in the GR are a workaround, not a solution. On a sidenote, I'm still wondering why front-desk (and afaict the DAMs) were never asked about their opinion while/after the GR was drafted. I had some chats with Anthony on IRC on the topic, but that was shortly after Debconf 6 (there was a related BoF), nothing in the past months. (not with the front-desk hat on, but having it within reach) PS: I voted "-1".

25 July 2007

Ian Haken: On Power Outages and Package Building

I'm sure few would disagree with me when I say that power outages suck. But on the bright side it gives me a chance to test the resiliency of my server setup. I haven't bought a UPS yet, mostly because I'm waiting until my next bulk purchase of hardware.

When I logged onto my home system from the office ssh gave me a friendly notice that a new IP for this hostname had been added to the list of known hosts. This flagged my attention since although I have a dynamic IP with my ISP, they haven't given me a different one for months. But it's reassuring to know that the program for updating automatically the DNS entry is working. I quickly figured out that there was definitely something wrong when my screen sessions were gone and PIDs were small. Sure enough, w reports the system has only been up for an hour and a half. Good to know the Full On BIOS setting works as well. Really aside from losing screen sessions, there was no real notice of the power outage. Well, that and I had to reset my alarm clock when I got home.

But back to the topic subject of summer of code, vlosuts is just about out of alpha now. For anyone wanting to try it out, here's the set of commands that'll build and install the package.

cd /tmp
svn co svn://svn.debian.org/vlosuts/vlosuts
cd vlosuts
debuild
cd ..
sudo dpkg -i vlosuts_0.1_*.deb
sudo vlosuts upgrade --config=/usr/lib/vlosuts/default.cfg


I haven't added debootstrap as a dependency yet, so make sure you've got that. Also make sure you have qemu/kqemu/kvm installed (depending on what backend you want to use; default is QEMU). Notice that vlosuts needs to be run with superuser privileges. This is a consequence of needing to mount and bootstrap the image. The "upgrade" part of the command line instructs it to perform an upgrade test (as opposed to just building an image or creating a vlosuts mirror file of the system).
You'll probably want to copy that config file and change the mirror to something local. Also make sure you've modprobed kqemu (or else it could take far longer than necessary) and if you're running amd64, either change the target arch to amd64 or set the qemu path in the config to /usr/bin/qemu-system-x86_64 (as of writing, kqemu on amd64 only works with this binary, not qemu). man vlosuts can also provide some information.

John Goerzen: OSCon Wednesday

Nat Torkington, program chair, started off the day. He commented that one of the most interesting trends these days is the expansion of the Open Source ideals beyond software.

Tim O'Reilly commented about the FSF's four freedoms, and asked how we maintain them. We have to think about preserving freedoms -- questions such as Free Software that relies on proprietary services, data, or business processes. It's important to remember to pay attention to freedom and not just to the success of businesses. But businesses matter and have enormous power and will always be related.

Tim really pushed expanding the boundaries of Open Source and thinking ahead: wikipedia, OpenID, etc. He also asked: does Congress need a version control system?

He suggested there are four open source success factors: frictionless software distribution, collaborative development, freedom to build/adapt/extend, freedom to fork.

Hadoop is an interesting FLOSS project to build some infrastructure like Google has. Apparently Yahoo is very interested.

Back to Nat... hardware is cheap and everyone keeps buying more of it.

James Reinders from Intel talking about multi-core parallelism. Saying that parallelism is going to be more and more important. Intel released threading building blocks, a series of templates for C++, as GPL'd software at the conference this week. I'm not all that excited about a C++ project, though, since I think languages like Haskell have more promise here anyway.

The other Intel guy mentioned Intel's open source involvement: intellinuxgraphics.org, intellinuxwireless.org, linuxpowertop.org, kernel,org, moblin.org. Linux laptops have the longest runtimes compared to other laptops.

"It's amazing how many people you can make paranoid by showing up with a tie and a suit to do a keynote at OSCON." -- James Reinders

Simon Peyton-Jones is up now, and Nat says he will "stretch your brain until only tiny bits are left."

State of the art in parallelism is really 30 years old with locks and condition variables -- like building a skyscraper out of bananas.

Locks are difficult to do right and have "diabolical error recovery".

Let's do transactions against memory instead of against a database. Implementation can even be similar to databases. The idea is transactional memory, and it sounds very, very slick.

Mark Shuttleworth and Tim for an interview...

Mark was fine, but I wish Tim had more interesting questions for him.

I went up to the front a few minutes after the event to talk to Simon PJ. He was talking to someone, who saw my nametag, and said, "Hi John, nice to meet you." He looked familiar but I couldn't quite place him, so I asked who he was. "Mark Shuttleworth." Yep, I was sitting just far enough back from the stage that I wasn't behind one of the large TV screens and couldn't make out faces real well, and I didn't recognize him. Erg..

24 July 2007

Martin F. Krafft: A user-space filesystem for mail labeling

I am still looking for a solution that allows me to tag my mails similar to what Gmail offers. Having thought about this for quite a bit now, I can see three solutions, implemented at different levels in the mail flow: as filesystem, patch to the IMAP server (Dovecot), or patch to mutt. Since this post is about the filesystem, I'll concentrate on that, but I'll also touch upon the other two solutions briefly.
A bit of theory First, let's dig into the theory and requirements for a bit. Instead of sorting mails into folders (one mail can only ever live in one folder), I want to tag my mails, such that a single message can have multiple tags and hence be relevant to multiple categories. If you want to think in terms of folders, then a single message could be attached to multiple folders, e.g. via hard links. This is what Mairix approximates. The problem with this approach is that simple operations, such as deleting a message (removing it from the enclosing folder) or marking it as read (renaming the file) only affect the message in the current folder, not its duplicates/clones in the other folders. So it's best to stay with a single file per message and to associate tags with it. Here, two approaches seem plausible: (a) extracting tags from the individual message files, and (b) storing tags/message pairs in a separate database. I have a gut feeling that (a) is the better approach, especially since the files we're dealing with all have the same format. And in fact, there is a semi-standard header for email messages to store such tags: X-Label. One more paragraph of theory: instead of simple tags, like Gmail provides, I want hierarchical tags, for instance:
X-Label: Debian::pkg::mdadm
X-Label: Debian::popcon, PhD::Debian::stats
Hierarchical tags work similar to folders in that any message tagged as Debian::pkg::mdadm also belongs to the Debian::pkg and Debian categories. No rocket science.
mutt Now it would probably be trivial to hack mutt and add a new layer of I mentioned earlier that this could be implemented in various places, and I'll start at the highest level, with mutt, the mail reader. For quite a while now, mutt provides search operators for the X-Label header, such that you can search or limit your mailbox e.g. like so: ~y \\<PhD::Debian\\> ~y \\<popcon\\>. The problem with this approach is that it reuses existing functionality, which I need on a regular basis: searching and limiting. Furthermore, I think this approach is hackish and brittle and exposes too much of the underlying workings. filters, which would be used in addition to the user-specified limit. On a high-level, the user would set a tag expression, like PhD::Debian ::popcon, and may additionally choose to limit the display of messages to those sent from the debian.org domain: ~f debian.org$. mutt would then assemble the pieces and apply the filter (~y \\<PhD::Debian\\> ~y \\<popcon\\>) ~f debian.org$ to the current view. With a reasonable user interface to specify or pick labels, as well as a simple label editor, this would almost cut the mustard. Thanks to the header_cache patch (which also indexes the X-Label header), mutt fares reasonably well on Maildirs with thousands of messages (well, not always), and binding keys like s (save) and d (delete) to appropriate actions to add and remove labels determined from the destination or the current tags filter, would make mutt a force to be reckoned with.
Dovecot Unfortunately, implementing this in mutt would mean that I'd be bound to the mail reader forever (and I like to pretend that's not the case, haha!). An alternative would be to implement this on the IMAP server, which already provides IMAP folders which are not necessarily bound to physical, filesystem folders and can intercept all commands that manipulate messages or their status. But while in theory this works fine, it'll break when offline tools, such as offlineimap come into play, as those (need to) instantiate every message they download, which brings us right back to the problem with duplicate/cloned files discussed before.
A filesystem idea Trying to stay independent of the tools I use, I started playing with the idea of implementing mail message tagging at the filesystem level, using Fuse. The user would run a daemon process against a given Maildir holding all mail (the base store) and export a virtual directory hierarchy in which tags become Maildirs, backed by a cache of X-Label:filename pairs.
  • the root folder contains one Maildir dor every tag present in all messages in the base store.
  • each of those Maildirs, in addition to the new/cur/tmp directories, provides a subdirectory for every tag minus the ones already in the path, recursively. Navigating to /PhD/Debian::pkg would result in a logical-AND query for all messages tagged PhD (and thus PhD::*) and Debian::pkg. I am not sure how to implement OR and NOT queries yet.
  • every Maildir in the entire hierarchy contains the messages satisfying the query inherent in the path.
  • the special directory /INCOMING can be used to write messages to the hierarchy in such a way that the cache gets updated. Alternatively, one could register inotify hooks with the kernel on the base store and let others write to it as usual.
  • the special directory /::UNTAGGED might enumerate all messages without any tags.
The virtual directory hierarchy should also export the familiar filesystem semantics:
  • creating a file automatically adds the tags encoded in the file's path.
  • copying, linking, and symlinking a file within the hierarchy are all equivalent and cause the tag associated with the destination to be added to the file.
  • copying, linking, and symlinking into the hierarchy should probably result in an error, unless the source is clearly an RFC822 message.
  • mkdir creates a new tag in the cache, but without any files associated with it.
  • rmdir removes tags without any associated files.
  • rm on a file removes a tag from a file. rm -r on a directory removes the associated tag from all files (and the cache).
  • moving files is equivalent to copy-remove, but needs to be atomic.
Unlike tagfs, which uses an external SQLite database for tags, this filesystem should not use an external database for tags, but rather a run-time cache. That way, tags can be propagated to other machines with IMAP synchronisation tools. Initially, I thought such a fileystem could even be deployed "underneath" the IMAP server, but then we obviously run into the same problems with offline tools as before. Potentially, such a filesystem could be incredibly powerful as it could do its work for any user agent directly dealing with Maildirs (such as mutt), and it could also be used as basis for an IMAP server which is only ever accessed synchronously (in online vs. offline mode). In the latter case, one would have to ensure that filenames don't change across IMAP operations, or use the message IDs instead from the start. But as good as it may sound, getting it to work right will require quite some attention, I think. Especially guaranteeing filesystem atomicity, as required for Maildirs, might be impossible through the Fuse layer.
The sad end Unfortunately, I don't have the time to implement any of the above, but if I did, I would probably try to patch mutt first, even though such a patch may not make it into the upstream source any time soon. The filesystem idea sounds cooler and cleaner, but it does not yet support OR/NOT queries, and it will be quite a task to implement and debug. On the other hand, dealing with Maildirs of several thousand messages in mutt is a bit of a pain if those Maildirs are being updated externally (e.g. mail is delivered to them). At least the idea is out now. If you are interested and want to work on this, please let me know so that I can link you up with other interested people. And if you have any other input, please let me know. And no, I don't really want to install emacs to read my mail. NP: Dream Theater: Train of Thought Update: I've created a mailing list for public discussion of this topic, so please subscribe if you're interested. Thomas Viemann suggested to use IMAP flags for the task, as these are standardised. However, I see two show-stoppers here: first, I am not sure whether it would be possible to set those flags from procmail on delivery (sieve can supposedly do it, but I consider sieve not adequate for my needs). And second, offline tools, such as offlineimap, which map IMAP folders to filesystem Maildirs, would have exactly the same problem with representing affiliation of a single message with multiple tags. You can read up on the discussion in the archives of the offlineimap mailing list, and soon the new mailtags list. Martin Scholl had the idea to extend dbmail with the concepts of virtual folders (or stored searches). Naturally, as database-backed mail system, it would be trivial and fast to implement, but this approach bears two problems for me: first, it also falls short with respect to offline tools (see above), and second it would require me to replace my entire mail infrastructure. I am not even considering the implications of using a database for mail storage.

Alastair McKinstry: Quote of the Day

"It is unlikely that Xoce is larger than Xatm , because the ocean initially exists below the atmosphere". From Enhanced atmospheric loss on protoplanets at the giant impact phase in the presence of oceans, Genda et. al, Nature, 2005. Tags ,

MJ Ray: Flash Floods of Weston

Although a small puddle formed uphill of our house, it soon soaked away, so I thought we'd got away without any problems from the unexpected Summer Rain [niq's soapbox] around here, but it seems I was wrong... Walking along Kewstoke Road yesterday, I was surprised to see sandbags outside one house. When I mentioned it in the greengrocer's, Nicky (excuse any misspelling) said they'd been sweeping the water flowing down the hill away from the shop door, as it would kill the wood floor and the electrics beneath if they didn't. It seems the other side of the hill also had some flash floods, reported in The Weston Mercury - News: The day the rains came down. Even so, it was much less than up-river in Gloucestershire and across in Oxfordshire, where Midcounties Co-op has mobilised its resources to combat flood chaos [coop news] by distributing essentials like water. It seems finding out whether you're in a flood risk area is unnecessarily difficult because the Environment Agency gives its reasons for stopping flood data being used [Free Our Data] - in short, they want to sell us our data a second time! In the longer term, it looks like things may change drastically around here if an entrepreneur from Burnham-on-Sea succeeds in his plan to wall in Weston-super-Mare with Severn Lake. (tip WWN ) What would that do to floods?

MJ Ray: Early Tour de France Audience Figures

Bloomberg: Tour de France TV Audiences Rise in Europe Even After Scandals (tip tdfblog ) reports audiences are up 6% in France, 11% in Spain and 40% in Denmark (to over 800,000). Italy's RAI reports 1.2million viewers, while ARD/ZDF averaged 1.4million until they pulled the plug over half a dope test. In the UK, the BARB Weekly Summaries show the tour's London-Canterbury Stage 1 charting with 178,000 viewers on itv4. That's up from 143,000 for 2006's stage 1 (up 24%). Last year's itv4 coverage seems to have peaked at 197,000, so it'll be interesting to see how later stages fare, as details are announced. Stage 1 was also shown on the more widely available (analogue+digital) itv1 channel. The itv1 coverage didn't chart, so it must have had less than 3.41 million viewers, but I can't see exactly how many. British Eurosport's reported audience for Stage 1 increased from 84,000 last year to 118,000 (up 40%). Their 2006 peak was 100,000 for the last Thursday highlights, so that's already broken. They've been advertising pretty widely, with really annoying Franglais adverts that mispronounce the race name ("Tardy France" eh?). There was also an overspill into other channels, which we don't usually see. Two of my favourites: Graham Jones: What do the Tour de France and a Victoria sponge have in common with your social networking web site? Channel 4: Tour de France's UK appeal (video feed) mms://a1167.v15478c.c15478.g.vm.akamaistream.net/7/1167/15478/v0004/origin.channel4.com/news/2007/07/05_bike.wmv

John Goerzen: Trip to Oregon

Last week, Terah, Jacob, and I boarded a train in Kansas. We were bound for Los Angeles, then would go up the coast of California, eventually winding up in Portland for OSCON.

Our first train was the Southwest Chief out to LA.

img_2926

Jacob had a great time on the train. This is a picture of Jacob and Terah in our sleeping car room. Jacob slept in his carseat at night and played with us during the day. See all recent photos of Jacob.

We had the option to get off the train for a few minutes in La Junta, CO. I took some photos trackside.

img_2962

Here's Jacob enjoying the lounge car. There were dozens of Boy Scouts on our train, heading to the Boy Scout camp near Raton, NM. Many of them hung out in the lounge car, so Jacob had plenty to watch and keep him entertained.

img_2995

The lounge car has wrap-around windows. We got an expansive view of the Rockies on the first day of our trip, and of the California desert on the second. This route really gives you a feeling of being alone sometimes. There are times where you can look out the window, and as far as you can see, there is no evidence of people or civilization.

Here's a picture out the lounge car, looking at the train as it rounded a curve.

img_2977

The lounge car was in the middle of the train, so the train really was longer than it might appear here.

We had a bit of an adventure in Lamy, NM. Apparently a terminal cancer patient was riding the train, and died in the night. We were held up for about 2 hours for authorities to arrive, perform their investigation, etc.

While we were there, passengers could get off the train and look around. I took a few photos there.

img_3000

This is a photo looking towards the front of the Chief. It uses bi-level cars, so every car has an upstairs and a downstairs.

Just outside the Lamy station is an old dining car. It is now a stationary restaurant. The restaurant had closed just before we arrived, but they let me in to take a few quick photos anyway.

img_3007

Just past Albuquerque, one of the two locomotives on our train failed. That meant that, combined with the delay at Lamy, we were more than 3 hours late into Los Angeles. That, in turn, meant that we missed our connection to the Coast Starlight. So the new plan was to take a bus to Bakersfield, then the San Joaquin train to Sacramento, where we could catch up with the Coast Starlight and get to Portland as scheduled.

img_3038

Jacob really enjoyed the Bakersfield train station. I carried him up to the stone walls, which he enjoyed exploring with his hands.

img_3034

This is the Bakersfield station. It's a nice building. But their large metal sign reads "To trains and busses." Someday I will forget about them misspelling "buses" on a large metal sign.

I've got two more pictures of Jacob at Bakersfield that you'd enjoy: one, two. He sure was a popular baby. We got countless compliments from strangers, and he got even more smiles and greetings from people. Even when he was fussy, people kept saying what a good baby he was. We were a little surprised at that. A few people even found his cry to be cute and funny!

img_3051

One of the nice side-effects of missing our connection was seeing the grand old Sacramento train station. A beautifully-decorated building. We were there until about 12:30AM because the Coast Starlight had been delayed as well.

Terah saw a sign out the door saying "Quiznos: Now Open." I figured that meant that the store was open, not that the place was open late into the night, but she wanted to check. She stepped out and then back in again. "As soon as I got out, homeless people started yelling at me! Plus the store wasn't open," she reported.

img_3070

On the Coast Starlight, we discovered the absolutely stunning Pacific Parlour Car. These cars were originally built in the 1950s for the Santa Fe railroad, and have been renovated and restored by Amtrak for service on the Coast Starlight. That's the only train where they run, and they are available only to first-class passengers.

I noticed stairs going to the lower level of the Parlour, and was curious what was down there. So I went down to check it out, and it is a small (18 seats, I think) theater!

img_3087

We sat down there for awhile and talked to some of the other people.

The view from the Coast Starlight was amazing. The trip through the mountains was particularly nice. We saw mountains from the distance, up close, and at some points could look out our window directly down into a deep valley below. There were lakes, waterfalls, and little creeks all along.

img_3095

And finally, this is the grand Portland train station. Still an active station and a sight to see, though not as nice as Kansas City's.

So that's the trip to Portland. More to come on the convention and the city itself.

Adam Rosi-Kessel: Currently in the iRiver (7/2007)

Occasionally, I update my sidebar to reflect the current contents of my iRiver. Most people read this blog through the RSS feed, however, and never see the sidebar. So I thought I’d provide occasional snapshots here. Lately:

Ian Murdock: What a week

Steampipe explosion
I was in New York this past week meeting with a bunch of Sun customers and speaking at several Solaris related events. On Wednesday, just before 6pm, we were on a conference call in the Sun office at 101 Park Ave. when we heard a noise that sounded like thunder, and the whole building shook. When the noise didn’t stop, we stepped into the hallway and looked out the window to see 41st St. filled with what appeared to be smoke, debris hitting and nearly breaking the window, and people running down the street en masse. We filed down the stairwell and emerged into a scene straight from 9/11—shocked looking men in suits covered in a layer of brown debris, masses of people hurrying down 40th St. as fast as they could dashing across streets without regard for the traffic, cars honking their horns trying to get away through the throng, sirens blaring, cell phones not working, policemen doing their best to maintain control, people crying and holding each other, necks craning to see a plume of “smoke” rising into the sky high enough to obscure the Chrysler Buidling, and that awful roar that just wouldn’t stop. Of course, the “smoke” turned out to be steam, and the roar was the steam blasting out of an enormous crater on 41st that turned out to be just outside that window. But at the time, no one had any idea what was going on, and with lack of information comes speculation: It’s rush hour, they’ve blown up Grand Central Station, what’s next and when? It took a good hour before anyone knew it was just a steam pipe and nothing sinister. All in all, it was a pretty extraordinary experience that’s going to stick with me for a long time.

23 July 2007

David Welton: Dell Inspiron 1505 with Ubuntu

I'm writing this from the new Dell laptop I recently purchased which comes with Ubuntu preinstalled. Overall, I'm impressed - it's nice to get a laptop that "just works", without spending a dime for Windows. Everything seems to work quite well out of the box. The machine arrived earlier than Dell's web site promised, which is a good thing, because their promised date was a lot of time to have to wait. It's certainly no beauty - it's kind of thick, and a bit clunky, but hopefully it will be a good workhorse in the next few years. I need something reasonably fast, with a good screen, rather than something ultra-thin, flashy and super portable. The nits to pick: But I expect I'll get most of that figured out with a bit of fiddling, and the price was quite good, so overall I would highly recommend it to anyone else in my situation: wanting a Linux laptop that "just works" for a good price.

Simon Richter: Package management and components (aka "our users and free software")

Ian, I am not sure that “good package management” is a real selling point for anyone but system administrators. Home users do not care, as there is not that much difference between double-clicking an executable (that pops up a window, asks a few questions and then installs the software) and selecting a check-box in a list and clicking “apply” (followed by window, questions, etc.). In a business setting the users usually do not have permission to install software anyway, so they could not care less how it was installed, the only thing important is that it is there. In my opinion, the single technology that has had the most impact would be COM, the “Component Object Model”, because this is what the ISVs want: an easy way to define a (binary) interface that will allow components from different vendors to work together, ideally in the same virtual address space for maximum efficiency. The registry provides the necessary lookup functionality, so that you can construct an object of a given type by giving its class name or GUID to CoCreateInstance, and you get something back that provides the interfaces that this class implements, which is either the object directly or an RPC proxy. The latter happens, for example, when a multithreaded application wants to call methods in an object that is not threadsafe (COM will then serialize the calls) or when the object is provided by a system service (where we have dbus). The fact that the only thing you can rely on is the defined interface (a set of methods and data objects that map to getter/setter methods) makes it necessary to define the interface first and invest lots of Interfaces become immutable as soon as they are published, incompatible changes need a new interface name (that's where all the interface names ending in …2 or …3 come from). Under Linux, the closest thing is GNOME and their use of CORBA. If you were to write an application that runs within the GNOME framework, and if you wanted third party vendors to be able to plug into it, then you would probably publish an IDL file for it. Lots of “if”s there. Licensing is also an issue here. One thing the GPL fails to address, even in version 3, is the integration of components without linking into the same address space (which ORBit never does IIRC). Technically, the component provider and the component user communicate via sockets using a well-known protocol, so the component user is not bound by the GPL; the only thing that could be argued is that the IDL file defining the interface would be GPLd (although most jurisdictions consider interfaces as not copyrightable and/or permit “reengineering” for interoperability purposes). Some people might consider this “cheating” around the GPL, as any GPL'd program or library providing components could be used freely by any closed source application as long as the source code to the GPL'd portions was made available. Last (but not least) it is a matter of developer motivation. Third party vendors are, for most of us, not our target audience, and properly supporting them is going to be quite a bit of work. I've written about mixing different C libraries in the same executable image before, as a “nice to have” item. For components that should share the same image, like COM does, it is an absolute must, and COM goes to great lengths to make sure this actually works. For example, allocating memory that is to be passed to a COM method must be allocated using midl_user_alloc() from the RTC DLL and freed using midl_user_free() from the same; as this is a system library and compiler vendors are forbidden from bringing their own, everyone uses the same allocator pair (that internally just calls malloc() and free() from the Microsoft C library, but that is an implementation detail you are not supposed to know). On the Linux side, people do not care much about matching allocator functions, because in essence it all ends up in glibc's malloc()/free() anyway. When glib introduced their own allocators and started using them for their own structures, a number of applications started crashing unless you set a certain environment variable that told glib to pass everything through to glibc. Personally, I've spent the last days compiling toolchains in order to provide compiler packages that work “out of the box” on at least Debian etch, lenny and sid, and Ubuntu dapper, edgy, feisty and gutsy. Right now, I feel a lot like shipping statically linked binaries. Where Windows has mostly gotten out of the “DLL hell”, Linux has built its own variant of it:
The Windows DLL hell
is a hot place. Everyone is bringing their own grill lighter they believe does not cause cancer, starts a small fire and begins to roast marshmallows. The problem there is that the floor is covered with a sticky mixture of lighter fluid and everything is burning.
The Linux DLL hell
on the contrary is freezing cold. It has small isolated fires where a few friends are sitting, and they suddenly decide to move on and pour water over the fire and your marshmallows without asking first. Getting into a group is difficult, and if you manage it, all it means is that you are told to pick up your marshmallows before they extinguish the fire.
At this point, I'm going to be comment- and trackback-whoring; instead of answering the obvious question, I'm going to leave it open: Would a COM-style componentization model work in the Linux world, and attract software vendors, provided we can put out stable APIs and support them properly, or is that a red herring?

MJ Ray: End of the rubbish news

Both local papers are reporting that the council's investigations found nothing wrong but there's still nothing on North Somerset Council's web site. WWN: Reports that recyclable waste is being dumped in landfill sites have been rubbished by the council. The Weston Mercury - News: Recycling gets clean bill of health

MJ Ray: Has an easy-to-use UK map survived the "if it isn't broken yet, keep adding features" fad?

Recently, online mapping seems to be going through a period of "if it isn't broken yet, keep adding features until it is." I'm looking for a UK mapping web site which must include contour data (useful for bicycles), be usable without JavaScript and cookies (useful for mobile browsing) and be easy to write a search form for (useful for web links and bookmarklets); and should include aerial photos, postcode search and other countries. I used to use Multimap but it recently started requiring JavaScript and ditched the OS maps which showed the contours. Streetmap is still usable, but the visible copy of the beta site makes it look like they're about to make the same JavaScript-hungry mistake (emailed). Google Maps works without JavaScript and cookies (despite its whinging on the front page) but doesn't have contour data. And it's Google, who I don't like for other reasons. OpenStreetMap, Maporama, Mapblast and Ordnance Survey all seem to require JavaScript (OS despite their own accessibility policy - emailed). Map24 just seems broken in ways I've not debugged. So, besides Streetmap for now, is there an easy-to-use UK web map with contours?

22 July 2007

Daniel Stone: hackers

How not to obtain a copy of Hackers or Firewall in Birmingham at 10pm:

Next.

Previous.