Search Results: "ron"

16 October 2008

Adam Rosi-Kessel: Joe the Plumber isn t a plumber?

I haven’t been blogging this election at all recently — there are enough folks out there saying just about everything that should be said (and lots that shouldn’t), but I couldn’t let this little tidbit slip by without mention.Via the TaxProf blog: Also, the Trademark Blog notes the flurry of related domain name registrations. Technorati Tags: , , , ,

Sune Vuorela: Is something wrong with KDE patch backport policies?

Or Is distro’s backporting of features a good thing or Distro A is much better than Distro B because of the cool features So. Advantages when backporting features Disadvantages: In KDE4, several distros backports loads of features (Plasma panel autohide, plasma tooltips, kwin “cube” effect and other things).
Several distros include mandriva, suse, kubuntu and fedora. So should we in Debian follow the other distros? Should KDE change policies? Should distros stop backporting features? Something else? Sharing the patches among the distributions is of course easy. (Please note: I’m only talking about features, not bugfixes

Petr Rockai: adept 3.0 beta 4

I have released fourth beta of Adept today. For the unaware, Adept is an APT front-end for KDE: it lets you install, remove, upgrade software and such your Debian and Kubuntu boxes (and maybe on some other Debian derivatives, too). Changes since Beta 2 Since I have done beta 3 somewhat in a hurry, I have regressed the installer component badly — to point of complete unusability. However un-sound software engineering practice, the deep freeze for Kubuntu Intrepid hits today, so I have released beta 4 in rapid succession. Other than the regression fix, I have mostly reworked the paging implementation in the installer — however, the report of complete installer rewrite (hi Jonathan) is somewhat exaggerated. Sadly, the KPageWidget we have been using before turns out to be completely unsuitable for the job, so a quick rewrite probably fixed more issues than it caused (and this seems to be confirmed by early testing feedback). Moreover, this beta got a bunch of improvements to the search, including package name hits, a set of cosmetic improvements (button icons, nicer sidebar, etc.) and a button to run software-properties-kde from the Sources tab (works on Intrepid, but sadly breaks on Debian for now… will fix later. Need time, need sleep.) Where to get I have prepared binary packages. These should be now part of Debian Sid (unstable) and also of Kubuntu Intrepid. You should be able to get the new version from your distribution:
apt-get install adept
Again, as with beta 2, there is no Hardy backport, since my time is tight. If anyone is willing to do a backport please drop me a note: I will gladly publish installation instructions. Heroes of Beta 4 Jobs for Beta 5, RC and Final Mostly just testing and reporting bugs. I currently plan a beta 5 with a few fixes that have started accumulating since beta 4 already (mostly one-liner fixes with minimal risk of regressions). After that, an RC is in order and a final release (finally…). Notifier is not included. Kubuntu has an independent sort of notifier now, I believe. Maybe I’ll find time to reconcile it in 3.1 or so. Moreover, I assume that a beta 4 or a very minorly patched beta 4 will become part of Kubuntu Intrepid — there should be no major roadblocks left, so I hope everything will bode well for Intrepid. I assume that whatever becomes 3.0 final will be eventually included in Intrepid updates. And then, plans should be set forth for 3.1… Known issues The about dialog still says beta 2. Bummer. Please try to note in your reports that this is actually a beta 4 that you are using. I’ll make sure beta 5 fixes that — but it might be another week till then, or so. The Intrepid version should have that fixed, thanks to Jonathan Thomas (again).

15 October 2008

John Goerzen: The Best Photo Printing Services

When I first got a digital SLR camera a few years ago, I spent some time evaluating photo printing options. I sent a set of test prints to several different companies, and wound up deciding to use Shutterfly for my photo printing.

It's been some time since then, so I figured it was about time to re-evaluate options.

There are three main things to consider when obtaining prints of photos: cost of prints, quality of prints at delivery, and longevity of prints. Many people look only at cost, and those that look past cost rarely look past quality at longevity. Longevity (or permanence) is, in my opinion, the most important factor to consider. But let's look at all of them.

Longevity

All color photo print technologies fade or otherwise degrade over time. There are several main things that can cause this: exposure to light, exposure to gases (especially ozone), and exposure to humidity. The impact of these different items varies by print technology, paper, and process.

Longevity: Traditional Photo Paper

Most services such as Shutterfly, Snapfish, Ofoto, as well as retailers such as Walmart, Target, and Walgreens print on traditional photo paper.

Historically, traditional photo paper has had terrible fading characteristics. Typically, old photos exposed to light -- for instance, hanging on a wall underneath a light bulb or in the sun -- will exhibit severe fade towards yellow or magenta. Modern papers are much better, but you will still not want to leave them directly in the sun or under lights.

Over at TPR, you can find several papers analyzing this. Perhaps the most interesting are test of digital prints and image permanence: comparing the technologies.

To attempt to summarize, what you see is that of the two common consumer-grade photo papers, Kodak Royal and Fuji Crystal Archive, the Fuji paper has better permanence. However, the pro-quality Kodak Professional Supra Endura is better than either of them by a significant margin. The photo papers didn't really have a problem with humidity, and not much of a problem with ozone.

Longevity: Inkjet

So what about inkjets and laser processes? The main thing I learned from my research is that there is a tremendous amount of variance here. When looking solely at top-quality inkjet papers and inks, they ranged everywhere from having little bits of them flake off after a few months to doing better than any of the photo papers. This variance occurred even with similar papers from the same manufacturer.

As far as light exposure is concerned, every inkjet paper tested by TPR did better than Kodak Royal. Some fared about the same as Fuji Crystal Archive. And some even beat out Kodak Supra Endura.

But look at the ozone exposure test and you see a far different picture. All of the photo papers did really well, though suprisingly Supra Endura was the worst of them (though the scale is so small here that the difference is pretty minimal).

Not one of the inkjet papers came even close to that, and some faded so fast that they couldn't even make it halfway through the test.

As far as humidity is concerned, it barely impacted the photo paper prints at all. Inkjet impacts were still mostly small, but also were mostly more impacted than the photo paper.

Longevity: Laser

And finally, how about laser prints. There was huge variety here. An HP printer they tested faded so fast it couldn't complete the light exposure test, while a Konica-Minolta fared better than Kodak Supra Endura in one test. In another light exposure test, they performed about the same as the photo papers. Ozone had little effect on the laser papers, except for the Dell test, which faded so fast they had to abort the test early. Humidity also had little effect on the laser prints.

Longevity: Other Examples

Brett Wilson did some interesting experiments with photos hung in front of a window as well. Wilhelm Imaging also has done some research in this area, though they are done using fluorescent lights only, which is prejudicial in favor of inkjet papers and against photo papers.

For the ultimate in longevity, true black and white photo paper is well-regarded.

TPR also has a report covering different lacquer and other finishes often applied to prints to improve their longevity.

Longevity: Conclusions

With the exact right combination of inkjet paper and ink, you can get a print that will last exceptionally long. Some inkjet paper and ink combinations have really poor longevity characteristics, however, as do the laser papers.

Photo papers, especially Kodak Supra Endura, but even Fuji Crystal Archive, will last quite awhile as well, and are probably the best storage if kept in dark conditions such as an album.

Print Quality

When looking at print quality, I'm concerned with correct color balance, saturation, cropping, consistency, sharpness, contract, and detail in both dark and light areas -- the typical things you'd look for.

Printing inkjet prints at home leaves all this up to your printer, inks, papers, and you, so we can't really compare meaningfully.

Back when I looked at it, Shutterfly and Ofoto did the best. Walmart, Walgreens, dotPhoto, and many of the other online sites were really too poor to even bother with. Ofoto had a bit of a yellow tint to it, while Shutterfly did pretty well.

Most of the reviews of the major sites I've seen lately rank Shutterfly or Snapfish at the top in terms of quality. Many also rank Ofoto/Kodak near the top.

Walmart and Walgreens produce consistently bad results, and I only use them if all that matters is speed. If you ever read a review where somebody says that they get good results from one of those places, find a review where somebody has a better idea what they're talking about.

Besides your mass-market sites like Shutterfly and Ofoto, there are also some slightly more expensive sites. The two best-known are mpix.com and adorama.com. Mpix is a division of Miller's Professional Imaging, a pro lab. Mpix is basically a website where you can submit photos in the way you would to one of these other sites, and they can do their thing. Their standard rate includes human color correction on every print, but they offer a cheaper rate if you don't need that. Their standard paper is Kodak Pro Supra Endura (the one that ranked highest in longevity tests), and the options go up from there. They also offer printing on true black and white paper, as well as wrap-around canvas and other such options.

I've sent some work their way and have been exceptionally happy with the result. Everything from the color of the prints down to the packaging shows extreme care and attention to detail. Among the reviews that cover mpix -- many don't -- it almost always comes out at the top of the pack, easily beating out Shutterfly and Snapfish. It can be more pricy (though sometimes actually cheaper, since shipping is flat-rate with them), though not significantly.

Adorama is also sometimes mentioned. Most people seem to prefer mpix over adorama, but some prefer adorama. It's a bit cheaper when you don't need color correction for some prints, but sometimes -- right now, for instance -- closes for weeks at a time to observe Jewish holidays. It didn't seem to be enough for me to bother.

Cost

Perhaps the easiest to figure out is cost, since websites typically list it right there for you.

High-quality inkjet prints are by far the most expensive option. I looked at 4x6 prints. Using the high-quality paper/ink combinations that did well in the TPR tests, and when buying supplies in bulk to get the best possible discount, it's still 25 cents or more for a single 4x6 print. That's with doing all the color work yourself, and not even figuring in the cost of the inevitable experimenting with getting the software set up right and the wasted prints when ink gets low. It also doesn't figure in the cost of the printer.

At mpix, if you do your own color correction, it's 19 cents per print, plus shipping. Prints are on Kodak Professional Supra Endura Shipping is a flat rate of $3 for 50 or fewer 4x6 or smaller prints, or a flat rate of $5.95 for USPS Priority Mail for anything else. They offer FedEx at an additional cost, which maxes out at a flat rate of $12.75 for overnight shipping. Some items such as framed canvas prints are more expensive.

Other options at an additional cost include color correction by a human, metallic paper, Ilford B&W paper, etc. There are also some more typical pro-lab options: red-eye removal by a human, custom retouching, etc.

At Shutterfly, a 4x6 print goes for 15 cents. You can get them as low as 10 cents if you buy a pre-paid plan of 600 prints for $60. Shipping varies based on the number of prints, starting at $1.79 for up to 10 prints, ranging up to $21 for 500 prints, with 3 cents per print after that. Priority and express mail is available at an additional charge. Shutterfly's standard paper is Fuji Crystal Archive.

At Snapfish, a 4x6 print goes for 9 cents. You can get them as low as 8 cents if you buy a pre-paid plan of 250 prints. Shipping at Snapfish follows a complicated formula, but is generally approximately the same as Shutterfly. Though if you print more than 595 prints, watch out for the 10 cents per print overage fee. They don't state what paper they use. Recent reports seem to suggest that it's Fuji Crystal Archive, but some reports claim it's Kodak Royal.

My Conclusions

I'm planning to switch most of my prints to mpix -- their higher quality and cheaper shipping offset their higher per-print cost for me. Also, I plan to try out Snapfish and see what sort of quality I get from them for things where quality isn't really that critical.

Russell Coker: Programming and Games for Children

The design of levels for computer games is a form of programming, particularly for games with deterministic NPCs. It seems to me that for a large portion of the modern computer user-base the design of games levels will be their first experience of programming computers, the people who don’t start programming by creating games levels would be writing spread-sheets. Probably a few people start programming by writing “batch files” and shell scripts, but I expect that they form a minute portion of the user-base. I believe that learning some type of programming is becoming increasingly important, not just for it’s own sake (most people can get through their life quite well without doing any form of programming) but because of the sense of empowerment it gives. A computer is not a mysterious magic box that sometimes does things you want and sometimes doesn’t! It’s a complex machine that you can control. Knowing that you can control it gives you more options even if you don’t want to program it yourself, little things like knowing that you have an option of using a different choice of software or paying someone to write new software open significant possibilities to computer use in business environments. Games which involve strategic or tactical thought seem to have some educational benefit (which may or may not outweigh the negative aspects of games). To empower children and take full advantage of the educational possibilities I think that there are some features that are needed in games. Firstly levels that are created by the user need to be first class objects in the game. Having a game menu provide the option of playing predefined levels or user-defined levels clearly shows to the user that their work is somehow less important than that of the game designer. While the game designer’s work will tend to be of a higher quality (by objective measures), by the subjective opinion of the user their own work is usually the most important thing. So when starting a game the user should be given a choice of levels (and/or campaigns) to play with their levels being listed beside the levels of the game creator. Having the users levels displayed at the top of the list (before the levels from the game designer) is also a good thing. Games that support campaigns should allow the user to create their own campaigns. The KDE game kgoldrunner [1] is the best example I’ve seen of this being implemented correctly (there may be better examples but I don’t recall seeing them). In kgoldrunner when you start a game the game(s) that you created are at the bottom of the list. While I believe that it would be better to have my own games at the top of the list, having them in the same list is adequate. When a user is playing the game they should be able to jump immediately from playing a level to editing it. For example in kgoldrunner you can use the Edit Any Level menu option at any time while playing and it will default to allowing you to edit the level you are playing (and give you a hint that you have to save it to your own level). This is a tremendous encouragement for editing levels, any time you play a level and find it too hard, too easy, or not aesthetically pleasing you can change it with a single menu selection! When editing a level every option should have a description. There should be no guessing as to what an item does - it should not be assumed that the user has played the game enough to fully understand how each primary object works. Kgoldrunner provides hover text to describe the building blocks. Operations that seem likely to be performed reasonably often should have menu options. While it is possible to move a level by loading it and saving it, having a Move Level menu option (as kgoldrunner does) is a really good feature. Kgoldrunner’s Edit Next Level menu option is also a good feature. Finally a game should support sharing levels with friends. While kgoldrunner is great it falls down badly in this area. While it’s OK for a game to use multiple files for a campaign underneath the directory it uses for all it’s configuration, but it should be able to export a campaign to a single file for sharing. Being able to hook in to a MUA to enable sending a campaign as a file attached to an email as a single operation would also be a good feature. I have filed Debian bug #502372 [2] requesting this feature.

Martin Michlmayr: Debian on the QNAP TS-409U

Christmas came early for me this year: after receiving a Conceptronic CH3SNAS yesterday, a QNAP TS-409U showed up today. QNAP sent it to me a week ago to ensure that Debian works on it but it was stuck in customs for a few days. The QNAP TS-409U is similar to the TS-409 but comes in a rack case (and with more RAM). It seems that QNAP have also changed the layout of the mainboard but essentially it's still a TS-409. This means that the installer works just fine. Another difference to the TS-409 is that the TS-409U has two fans but qcontrol works without any problems on both machines.

MJ Ray: Poverty, Credit Unions and Community Banking

Today is Blog Action Day about poverty. As a member of several cooperatives, I have a pretty strong hope that the responsible lending of credit unions can help people escape from poverty. The basic process of a credit union is that you save for a while, then when you’ve shown that you will put aside that amount of money regularly, you can borrow some multiple of it and repay at the same rate you were saving. In addition, you get a voice in controlling the credit union itself, although it is limited by financial services regulations and so on. At yesterday’s meeting of the Cooperatives-SW board in Taunton, some members expressed concern about a “social enterprise” called South-West Pound backed by a company called South West Community Banking Partnership. Although it’s called that, apparently it’s not a bank and also not a credit union: its members don’t manage it. It’s working with credit unions, but I’m very unclear on how it’s regulated. From the few details on their website, it looks to me like it could even be running a Farepak-style scheme which happens to hold deposits in credit unions instead of banks. Why is concealing member-controlled unions allowable as a “social enterprise”? Why would anyone go to a “community banking partnership” instead of direct to a credit union? (Coo, I’m getting a bit angry again, both at the lack of information and the hide-them-to-promote-them idea.) Tomorrow (Thu 16 Oct) is International Credit Union Day. If you’ve not already done so, please go open an account and help your local community to fund itself, then see if you can get involved in publicising them to communities who suffer financial exclusion.

Martin F. Krafft: Fixing the credit crunch problems the wrong way

We re all aware of the financial crisis due to credit default swaps shaking up the markets, media, politics, and what not. Some of us are feeling the pain, most of us aren t yet. A few days ago, politicians of the big, capitalist nations convened to agree on a way forward to stablise the financial market and set an end to the crisis. They are planning on doing this by throwing hundreds of billions at the market, buying all the subprime loan packages with the intention to create a new market for them, thus taking the weight off the shoulders of the countless barely-surviving banks and investors, who have written off billions in losses without an end in sight. Where does this money come from? Taxes and newly printed money. You may not yet feel the effects of this, but you will: taxes will rise, and inflation soar to even higher levels. Today is Blog Action Day with poverty as the focus, and it s a good occasion for me to state what s long been on my mind. The strategy by our political leaders to combat the credit crunch is short-sighted, and it fights symptoms, not causes. In fact, it s Robin Hood played in reverse: tax increases and inflation will hurt those most who cannot do anything against it: the poor. On the other side of things, those active in the financial markets will have their damages limited, and new CDS markets might even create more opportunities for those who can. I strongly oppose the way our politicians are handling the issue, even though I do have small amounts of funds invested in financial products myself, and have already seen the positive effects of their actions. Rather than throwing money at the markets, we really ought to put those away who have caused all this, those ruthless, greedy ones who have speculated way over their heads, underestimated the risks, and caused this crisis that killed many businesses, threatens to endanger entire countries, and hurts individuals who hardly ever had a choice. Think of it as a driver s licence, and that should be revoked for those who screwed up so royally bad and got us into this situation in the first place. Don t let them speculate again! Update: Andreas Metzeler notes that he is (rightfully) missing a what is to be done instead section in my blog post. I don t have anything to offer on that front, sadly. I also realise I should have phrased my opposition differently. Reading this interesting interview with Deutsche Bank ex-CEO Hilmar Kopper (German only) (thanks, Andreas!) helped me understand more that the politicians aren t saving banks, they are saving the system, and that they have little other choice. Another aspect I haven t previously seen as clearly as now is that the governments are purchasing (and willing to carry) risk for others, to relieve the markets. Risk by itself doesn t cost anything, so it might turn out that the billions they made available won t actually be spent though I always new that the governments might well come out of this with a profit even. The whole affair still stinks, and what I truly miss are the actions to prevent those responsible for getting us into this mess in the first place from doing so again. NP: This Will Destroy You: Young Mountain

14 October 2008

Joey Hess: NC car curse, part 4

I'm getting to the point that I fear driving in North Carolina, because an exceptional percentage of car breakdowns happen to me there. The most recent one actually didn't happen in state, I'd just passed the TN border and was coming down the exceedingly twisty road to Shady Valley when I lost the engine on Mom's car. About the time I gave up on letting it cool down and trying things, a white convertable pulled up and I got a lift down to Shady. Since this was a beautiful Sunday, the country store there had at least 500 motorcycles out front. I borrowed one of the bikers' cell phones, called a tow, and sat in a rocker on the porch and watched the insanity for an hour. The good thing about driving old cars that sometimes break down is that you do get used to dealing with it. I actually enjoyed 95% of the incident. Oddly, the car started without problems the next morning. Curse indeed.

Joey Hess: electic bike

I decided to get an electic bike when my car died. Couldn't quite stomach buying a new gasoline vehicle at this point in time, didn't really feel like another used car, and the available electic cars are still too new/expensive/hard to find. While there are some neat NEVs that are not too expensive, they're too limited to be worth my money, and electic bikes fit into the same general niche. (So do electic scooters, but I didn't want to spend that much money on an experiment..) My first try was a disaster. I was thinking that a large cargo capacity would be a good thing, so I gravitated toward trikes. However, the one I tried turned out to be a lemon in several ways, and suffered a catastropic and dangerous controller burnout. So I learned that this electic bike industry is pretty rough and ready with a lot of junk to avoid. I also learned that I don't enjoy riding trikes. The second try was a R Martin LX1, which my dad had researched. I got it yesterday, and have ridden it some now, and I agree that it's a good one. As a bike, it's well built, has a good back disc brake and decent front brake (will be better once I bring it to a bike shop to adjust it better), has a good derailer, and rides well. I'm no expert but it seems about as good as the bike I used to commute with, though the frame is a bit heavier. (IIRC, it was also at least $200 cheaper than that bike!) On the electic side, it has a relatively small and light lithium ion battery; the motor is mounted in the hub. It's strong enough to go up hills on its own if you really want it to, but you will end up pedaling to assist, which is good. I'm undecided whether the six gears are enough ... Seems like I might want a faster gear, to be able to assist the motor more at high speed. I haven't wanted a lower gear yet, but I've not tried to do any hills without the motor's help. The electic controls are ok, but not perfect. I worry about accidentially twisting the throttle, although it has to be turned quite far to engage the motor. Ideally, the pedal assist would turn the motor on exactly when you pedal, and porportionally to how hard. Instead, there'a a lag, and doesn't care how hard you pedal. This can present problems coming up to an intersection or other hazard, where pedal assist kicking in can unexpectedly be more speed than is needed. Seems a waste to have to brake to cut the assist off. The motor is audible when accellerating, and especially complains when trying to get me up a hill on its own. At speed, or if given a human power assist, it's quieter than the chain, if not silent. So there's room for improvement (and this would be a fun thing to do some hacking on to improve its response), but it's still a lot of fun. I'd forgotten how much I enjoy riding a bike and getting a nice workout. And it's especially nice to go up a hill pedaling only as hard as you like, to be able to accellerate quickly without standing on the pedals, and to be able to "coast" a long, long, way.

Adeodato Sim : Le petit Nicolas is made of awesome

Every night I can, I sit with my sister and we read half a chapter of Le petit Nicolas, in French. I read aloud, and she fixes my pronunciation. She says I’m doing well! I’m also getting to understand increasingly more and more (she helps along the way with that). I’m not sure whether it’s the magic of being written in French, or what, but I’m finding it very nice, and we laugh a lot. Maybe if I’d be reading it in a language I was fluent in it would not be the same. But, if you ever end up learning French, be sure to give it a try!

Bdale Garbee: YikStik

As some of you know, the first weekend in October was a big deal for me, because it was NCR's Oktoberfest launch event. My son and I spent the weekend camped out on the prairie with Keith Packard and many of our other friends. Keith successfully went from nothing to a "level 2" high power certification, which was pretty cool. I wasn't quite so lucky. On Saturday morning, I flew my custom-designed rocket YikStik for a "level 3" certification attempt. The name comes from the word my wife uses to describe lipstick. The rocket was built from a mixture of custom and Giant Leap parts, including 98mm Dyna Wind airframe, a 98-75mm tail cone retainer, and a Pinnacle nose cone. All the centering rings were cut on my 3-axis CNC milling machine, and the fins were custom 7-layer composite layups using plywood, carbon fiber, fiberglass, and epoxy... all vacuum bagged using a kitchen food saver appliance. Painted red, gold, and black, with a custom 8 foot main parachute sewn by my wife Karen from the Team Vatsaas design in red and black rip-stop nylon. The motor selected was an Aerotech M1297W reload. This is a 75mm diameter motor 66.5cm in length with 2722 grams of propellant yielding 5417 Newton-seconds of total impulse. It was also on sale earlier this year for cert attempts. My simulations said YikStik should have flown to about 14,800 feet above ground level at the NCR north site on this motor. The launch went perfectly, and the rocket was stunningly beautiful under boost. It disappeared into some high clouds, but we continued to have strong signals from the two tracking transmitters installed in the payload bay behind the nose cone. About the anticipated time after launch, we saw a rocket descending under chute in the distance, and headed in that direction. A few minutes later, we abruptly lost both tracking signals, and that's when things took a turn for the weird. In hindsight, I think we suffered an apogee deployment of the main chute, and the rocket we saw descending was someone else's. YikStik was designed to deploy a streamer at apogee, then descend fairly quickly to about 1500 feet above ground where a second set of ejection charges would fire to separate the nose cone on a 3 foot drogue parachute that would pull a deployment bag containing the main chute out of the airframe and then pull the bag off the chute. The nose cone, payload bay with the tracking transmitters, and deployment bag would then descend under the drogue chute and the remainder of the rocket would descend under the big chute. In the world of deployment bags, this is called a 'free bag' configuration. With deployment at 1500 feet, the two bits should have landed within sight of each other. But that didn't happen. It wasn't until late Sunday afternoon, after we had to leave to get Keith to the airport, that some friends finally located the nose cone assembly about 3.5 miles down range from the launch site, over a couple rises and past an area of rough terrain. By then it was cold, windy, and rainy, and so I really appreciated the effort they put in locating the nose, and wasn't too surprised that they didn't immediately see the rest. Since the bulk of the rocket under the main should have had a slightly higher descent rate than the nose cone, I expected to find the rest of the rocket somewhere near a line between the launch rail and where the nose cone was discovered. So last Wednesday I spent about 5.5 hours walking around the area searching... but no luck. Since then, several other people have been out looking for my rocket, including two friends who flew over the area today in a light plane looking down into all the washes. Still nothing. I posted some signs in the area with a photo of the rocket and my contact info, I hope someone calls eventually. In the meantime, the bulk of YikStik remains missing, and of course I did not achieve a successful level 3 certification. Lessons learned for next time are that tethering the deployment bag to the main chute instead of flying in a "free bag" configuration might have been a better choice, and it's kind of silly having two tracking transmitters in one of the two pieces of your rocket and none in the other... Ray LaPanse took some stunning photos of the launch. He will likely post better versions with color correction and so forth at some point, but in the meantime, I've put a few up on my Garbee Rockets web site. She sure was a beauty!

Patrick Schoenfeld: Extending Debian with customizable packages

In my previous post I drafted a rough idea how to add a feature to Debian that would bridge the gap between Debian as a Binary Distribution and any Source Distribution. The feature in question is giving users the chance to build customized Debian packages for specific feature sets. The possible use cases are simple:

Lets say Anthony User needs super-duper-tool with postgresql support. However this is a not so common use case and so the archive only has postgresql support. If he now wants to build a custom package, the process is "as simple" as:

apt-get source super-duper-tool
cd super-duper-tool-*
apt-get build-dep super-duper-tool OR sudo mk-build-deps -r -i
(possibly try out which ./configure options are supported by super-duper-tool)
vi debian/rules
edit debian/rules
dpkg-buildpackage -us -uc
sudo debi

That is, to be honest lot of work. And the biggest problem about it is that you need to know all this, which is not really user knowledge.

The basic idea is that Anthony can do something like
export DEB_BUILD_OPTIONS=nomysql,postgresql
deb-build-tool build super-duper-tool

and is done.
So the question is how could this be achieved?

  1. Define a set of common options (options should be consistent through all source packages, otherwise it makes not that much sense) that every package should support, if it is a supported feature by the package in question. This includes flags like mysql, postgresql, ldap and its no-equivalents (nomysql, nopostgresql) to negate it.
  2. Enable use of this common options in the package build process and that is really the hardest part. Defining a lot of ifneq..findstring constructs for 2-10 options per source package in any available source package is.... not.... a good approach. Luckily a lot of packages uses autoconf where enabling and disabling features is as easy as adding a --with-foo or --enable-foo option to the ./configure parameters. So we could write a wrapper that would handle these options. The debhelper scripts already have dh_auto_configure: Maybe this could get enhanced.
  3. If it does not exist: Write a tool to auto-build packages with DEB_BUILD_OPTIONS set by the user. Should automatically get the source, (optional: setup/update a pbuilder environment) and build it and optional install/upload it (to a user repository for example) .
Still, the idea is only a rough draft. There are still a lot of open questions/issues, for example:
Is anybody interested in pushing this idea forward? I'm happily interested in it and I know people who like the idea, too. But I can't push this forward on my own all alone. Certainly the work won't affect Lenny anymore, but considerable the time frame that is planned for Lenny+1 by the release team, this could be a feature for Lenny+1.

Martin Michlmayr: Conceptronic CH3SNAS and the D-Link DNS-323 revision B1

Conceptronic kindly sent me a CH3SNAS for my Debian porting efforts. The Conceptronic CH3SNAS is reported to be basically the same hardware as the D-Link DNS-323 but it costs slightly less. There were some reports that the CH3SNAS uses a 88F5182 chip whereas the D-Link DNS-323 uses a 88F5181 but nobody was able to confirm this for sure. As it turns out, there are two revisions of the DNS-323. Revision A1 uses a 88F5181 chip along with a separate SATA chip. Revision B2 on the other hand uses a 88F5182 which integrates SATA into the SoC itself. The CH3SNAS is equivalent to a D-Link DNS-323 revision B1. In fact, the mainboard of the CH3SNAS even says DNS-323 rev B1. The Linux kernel from mainline only works on the DNS-323 revision A1 at the moment. Adding support for revision B1 should be trivial since you basically just need to initialize the SATA chip on the SoC and possibly adapt some other values. Unfortunately, the DNS-323 uses a very small serial connector so none of my serial cables work. If I can find someone who will make a serial cable for me, I'll fix up the kernel.

Sune Vuorela: Skolelinux/Debian-edu gathering infiltrated by Gnash people

Gathering
I spent this weekend at a Skolelinux/Debian-edu gathering in Oslo. 8.5 hours by bus each way. I got to meet some of the people shipping a customized Debian for schools. As it was a gathering related to educational software, looking at the KDE4 kdeedu packages seemed most appropriate. I’ve tested step packaging and hopefully it is going to end up on your local debian archive one day, along with some fixes to where kvtml files are packaged, much awaited by Annma and others. Apparantly, in Brazil, they have their own debian based kde distribution and 130 GB of free as in public domain free educational movies. Some people discussed an application to view, tag and search the movies. I quickly thought of a mixup of nepomuk and phonon in a nice userinterface. So if anyone feels like implementing that, you are more than welcome. Gnash
The gathering was together with a Gnash hackathon, and apart from gnash getting more and more usable, the gnash people are also thinking about integration with the desktop environments. For KDE 4 they have plans of a KPart easy embeddable anywhere, including in KHTML. (Maybe another use of the KPartLoader dfaure wrote recently). The gnash team are unfortunately quite short on KDE knowledge and they asked for help. I’m probably not myself the right one to help here, but maybe some of you out there feel like helping. There is already a patch set around that some people claims works, but others haven’t figured out to make it work. Feel free to comment here and I will forward to the Gnash people - or just contact them directly on the gnash-dev@gnu.org maillist. Trolls
I left the gathering a bit early to get to a Troll picnic in a Oslo park and got stuffed with p lse and lompar. (sausages and pancake like bread) I was by bus all night back home and then a shower and straight to work. After work, I slept for 14 hours or so.

13 October 2008

Russell Coker: Some RAID Issues

I just read an interesting paper titled An Analysis of Data Corruption in the Storage Stack [1]. It contains an analysis of the data from 1,530,000 disks running at NetApp customer sites. The amount of corruption is worrying, as is the amount of effort that is needed to detect them. NetApp devices have regular “RAID scrubbing” which involves reading all data on all disks at some quiet time and making sure that the checksums match. They also store checksums of all written data. For “Enterprise” disks each sector stores 520 bytes, which means that a 4K data block is comprised of 8 sectors and has 64 bytes of storage for a checksum. For “Nearline” disks 9 sectors of 512 bytes are used to store a 4K data block and it’s checksum. These 64byte checksum includes the identity of the block in question, the NetApp WAFL filesystem writes a block in a different location every time, this allows the storage of snapshots of old versions and also means that when reading file data if the location that is read has data from a different file (or a different version of the same file) then it is known to be corrupt (sometimes writes don’t make it to disk). Page 3 of the document describes this. Page 13 has an analysis of error location and the fact that some disks are more likely to have errors at certain locations. They suggest configuring RAID stripes to be staggered so that you don’t have an entire stripe covering the bad spots on all disks in the array. One thing that was not directly stated in the article is the connection between the different layers. On a Unix system with software RAID you have a RAID device and a filesystem layer on top of that, and (in Linux at least) there is no way for a filesystem driver to say “you gave me a bad version of that block, please give me a different one”. Block checksum errors at the filesystem level are going to be often caused by corruption that leaves the rest of the RAID array intact, this means that the RAID stripe will have a mismatching checksum. But the RAID driver won’t know which disk has the error. If a filesystem did checksums on metadata (or data) blocks and the chunk size of the RAID was greater than the filesystem block size then when the filesystem detected an error a different version of the block could be generated from the parity. NetApp produced an interesting guest-post on the StorageMojo blog [2]. One point that they make is that Nearline disks try harder to re-read corrupt data from the disk. This means that a bad sector error will result in longer timeouts, but hopefully the data will be returned eventually. This is good if you only have a single disk, but if you have a RAID array it’s often better to just return an error and allow the data to be retrieved quickly from another disk. NetApp also claim that “Given the realities of today’s drives (plus all the trends indicating what we can expect from electro-mechanical storage devices in the near future) - protecting online data only via RAID 5 today verges on professional malpractice“, it’s a strong claim but they provide evidence to support it. Another relevant issue is the size of the RAID device. Here is a post that describes the issue of the Unrecoverable Error Rate (UER) and how it can impact large RAID-5 arrays [3]. The implication is that the larger the array (in GB/TB) the greater the need for RAID-6. It has been regarded for a long time that a larger number of disks in the array drove a greater need for RAID-6, but the idea that larger disks in a RAID array gives a greater need for RAID-6 is a new idea (to me at least). Now I am strongly advising all my clients to use RAID-6. Currently the only servers that I run which don’t have RAID-6 are legacy servers (some of which can be upgraded to RAID-6 - HP hardware RAID is really good in this regard) and small servers with two disks in a RAID-1 array.

Julian Andres Klode: I am a Debian Developer now!


14 months after applying for the NM process, I’m a Debian Developer. On Mon, Oct 13, 2008 at 10:51:43PM +0000, Martin Zobel-Helas wrote:
> [ This is a long mail with important information, so please read it all
> carefully. ]
>
> Dear Julian Andres Klode!
>
> Your account ‘jak’ has just been created in the central LDAP
> database of the Debian project. [...] Thank you everyone (in chronological order):
  • Daniel Baumann (daniel) - Sponsored my first packages
  • Joerg Jaspert (joerg) - The first DD who signed my key
  • Niv Sardi-Altivanik (xaiki) - Advocated me for NM
  • Martin Zobel-Helas (zobel) - My first AM
  • Alexander Reichle-Schmehl (tolimar) - The second DD who signed my key (at CeBIT)
  • Bernd Zeimetz (bzed) - Took over in June, because zobel was very busy
  • Christoph Berg (myon) - For checking the AM report and requesting the account creation
  • Jonathan McDowell (noodles) - For adding me to the keyring
  • Martin Zobel-Helas (zobel) - This time for creating my account
And many thanks to Google - for helping me to find answers to important questions. Without you, I would know nothing. And of course all the others who helped to make this possible. Posted in Debian      

Decklin Foster: What's sup?

After some weeks of final testing, I've just uploaded packages for sup-mail to NEW. I'm pretty excited about this. Sup is a console-based MUA, like mutt (which I have used for many years). A few things distinguish it from most mail readers targeted at geeks like us:
  • Sup has no folders, a la Gmail. After watching many friends and even fellow hackers switch to Gmail, I have to admit: this literal hierarchical organization thing doesn't scale. I was planning to totally redo my mail folder system Any Day Now for about six months prior to starting on this. It was never going to happen.
  • Sup uses a Ferret full-text index to make this approach plausible. Search is super fast and beats (for me) both any kind of "organization" I could have disciplined myself into and the fine-grained control of something like mutt's search. It's sort of like git: until you do it, you don't realize how much more productive you can be when previously-expensive operations become instantaneous.
  • Sup works with threads, not messages; this is another thing Gmail got right. I used to waste brain cells thinking about which messages in a thread were worthwhile enough to save or not. Given the absurdly cheap price of disk relative to what we can type out in plain text since, like, a decade ago, this is crazy. In the index, I only have to look at whether a thread has new chatter or not, not its size, shape, or where the new messages are relative to it. All that's in the thread-view buffer where I actually read content.
  • Sup is written in Ruby. Back in the dawn of time, I used Gnus, and while I wasn't very good at elisp, the hackability afforded by being written in a high-level language was very nice compared to programs mostly implemented in C (even if they had a tacked-on scripting language). Plus, I love Ruby right now.
Despite all of those wins, sup currently has many drawbacks, and I don't recommend it for everyone. (And I mean everyone who thinks that the above are good ideas and are interested in using it; plenty of people, I'm sure, already think everything about this is idiotic, not new, or inferior to their preferred MUA. That's fine! You can ignore it all.) Here's what's still problematic:
  • At version 0.6, sup is very much not-yet-1.0. While it handles insanely large amounts of email without breaking a sweat, I still keep an additional backup of everything. (If Ferret crashes, the original copies of mail will be untouched, but it never hurts to be paranoid.)
  • The flow of data from your physical mail store to the sup index is currently one-way only. Actually removing deleted/spam messages is a big hack (if it works at all), and labels/flags/etc live entirely in Ferret-land. If you want to manipulate an actual mailbox, mutt is still the tool for the job (and then, you need to re-sync sup). This is probably the deal-breaker for most of us. I jumped in anyway because I feel like it can be solved (or more likely, made irrelevant) later.
  • William (upstream) is currently re-designing the whole thing from scratch, replacing the index library with Sphinx, and decoupling the index from the console frontend. As a result, the previous item is pretty much a non-priority (and bugs in general are not going to get the same amount of love as usual). I am hoping that we end up dumping mail into the index directly, then writing more frontends to write to Maildir backup, serve as webmail/whatever, but this is a long way off. On the plus side, thanks to Thrift, they will not be limited to Ruby.
  • Ruby's ncurses library still doesn't handle Unicode correctly. It can be patched (still doesn't work totally right), but I'm trying to find a more permanent solution for Debian.
So, if you're interested enough that you want to deal with these warts for now, apt-get install sup-mail (as soon as it hits the archive) and join us! Hopefully being in Debian will increase the userbase and get things fixed faster. If you're unsure, stay tuned for the next-generation version later. (There are screenshots and a few introductory docs over at Rubyforge that illustrate and explain all this in more depth, which I recommend checking out if you're still saying, "...huh." Me, I'm a sucker for any piece of software with a manifesto.)

Jose Carlos Garcia Sogo: Compiz

Today my 5 years old laptop gave me some filesystem problem after running apt-get update, which resulted in some corrupted packages, among them libc6, with the result of my system becoming non-functional. So I needed a recovery CD to be able to mount read-only root partition. I had around an Ubuntu 8.04 Hardy Heron LTS, so I used it to run its included LiveCD and recover from there. At the same time I was curious about it, as I hadn’t had chance to test it before. One of the things that surprised me most was that Compiz was enabled by default. After a second thinking that this was going to be a problem, making the system unusable (remember, a 5 years old laptop, and I had checked myself compiz some time ago with a catastrophic result), I started to meve windoes, jump from one virtual desktop to other, and minimiza and maximize windows without a problem. The work that had been made amazed me! So, some fsck and apt-get commands after, I managed to reboot on my Debian system, and I installed compiz. The result: my system goes faster using compiz, with a bunch of effects enabled than running plain metacity window manager. I have a also installed some compiz fusion plugins, and they are running without a glitch and with an incredible speed. Obviously, I have not chosen full quality, but it is enough to show effects in an efficient way. I have improved my user experience and system speed at the same time… Once again Linux shows that it can get the best of old hardware. Good work, guys!

Steve Kemp: Then don't knock it, it's got it's own key.

ObRandom:
Any blog post, comment thread, question, or email which starts "Hi guys" is bad, wrong, and probably not worth reading.
ObTitle: Dawn of the dead - the original and best version - 1978

Next.

Previous.