I've gotten this question a few times. "Would SDcards make a good ZIL device?" "Would SDcards make good ZFS devices?" The answer to both is resoundingly no.
The reason for this is simple, and is the same reason you should never reformat SDcard media using your computer.
It boils down to the fact that you need to do some very "SDcard" specific optimizations when you layout your filesystems in order to get good performance. (The details for this are only available after signing an NDA with the SDcard trade association, btw.) Of course, general purpose computers use general purpose filesystem code, which is targetted for hard disks. So the optimizations, if there are any, are all wrong for SDcard media. (Note that this only matters when doing the initial filesystem layout .... i.e. when you are formatting the media.)
You can reclaim at least some of the performance you might have lost if you've made this mistake, by reformatting the media in your camera. But unless you have a much fancier camera than I do, your camera probably doesn't speak ZFS.
Monday, October 26, 2009
hacking perl to help my kids at school
So I have three kids, and they are all in elementary school. And right now all three of them are still trying to memorize their multiplication tables. Apparently the schools these days teach the kids to start by "counting up" (3, 6, 9, 12 ... etc for 3's) rather than going straight towards memorization as I recall we were taught.
So now they're still counting up, and have not memorized these basic facts.
So I had the idea that we need to give them sheets with practice problems, like the timed ones they do in school. I figure if they have to do this a lot, then eventually the facts will just "sink in".
This is when the wife pipes up: "hey can you write a program to do that?" (If only I had a nickel for every time the wife asked "can you write a program to do that?"...)
Well, this one was easy, took me about 20 minutes in perl. I wrote a script, "problems.pl" that dumps text file of some 144 problems suitable for sending to the printer. Here's sample output:
Command line switches: "-r" to randomize the problems a bit (although every problem is given), "-s" to set the numbers to start from, and "-e " to set the ending problem (note that the second values are constrained from 1..12, because that's what the kids in school need), "-S " to set a seed (so can regenerate a previous sheet) and "-a" for an "answers sheet" (which is really only useful if you want the child to use it to check her own work. Because you should know all these facts so cold that you can check without an answer key, right? Right?)
Here's the code. Feel free to pass it around, give it away, modify it, whatever. It can be adapted to other kinds of problems pretty easily, I expect. Maybe you know a teacher or parent who could use this dumb little script. Maybe you just need to practice your multiplication tables on your own? I won't tell!
So now they're still counting up, and have not memorized these basic facts.
So I had the idea that we need to give them sheets with practice problems, like the timed ones they do in school. I figure if they have to do this a lot, then eventually the facts will just "sink in".
This is when the wife pipes up: "hey can you write a program to do that?" (If only I had a nickel for every time the wife asked "can you write a program to do that?"...)
Well, this one was easy, took me about 20 minutes in perl. I wrote a script, "problems.pl" that dumps text file of some 144 problems suitable for sending to the printer. Here's sample output:
gdamore@pepper{18}> perl ~/problems.pl -r
Practice: (# 650)
Times tables from 1 to 12.
All mixed up!
4 x 7 = 5 x 7 = 1 x 10 = 2 x 9 = 10 x 9 = 6 x 7 =
12 x 10 = 1 x 4 = 2 x 5 = 6 x 3 = 5 x 12 = 11 x 8 =
2 x 12 = 1 x 1 = 7 x 4 = 3 x 10 = 9 x 10 = 6 x 11 =
Command line switches: "-r" to randomize the problems a bit (although every problem is given), "-s
Here's the code. Feel free to pass it around, give it away, modify it, whatever. It can be adapted to other kinds of problems pretty easily, I expect. Maybe you know a teacher or parent who could use this dumb little script. Maybe you just need to practice your multiplication tables on your own? I won't tell!
#!/usr/bin/perl
use Getopt::Std;
my $start = 1;
my $end = 12;
my @problems;
sub usage() {
print STDERR basename($0), ": usage\n";
print STDERR "problems: [ -r ] [ -a ] [ -s] [ -e ]\n";
exit(2);
}
srand();
$seed = int(rand(1000));
my $s, $e, $i, $j;
getopts('rs:e:aS:', \%opt) || usage;
$dorand = exists($opt{'r'});
$doans = exists($opt{'a'});
$start = $opt{'s'} if exists($opt{'s'});
$end = $opt{'e'} if exists($opt{'e'});
$seed = $opt{'S'} if exists($opt{'S'});
srand($seed);
$i = 0;
$s = $start;
$idx = 0;
foreach $i (1..12) {
foreach $j (1..12) {
$problems[$idx]->{'problem'} =
sprintf("%2d x %2d = ", $s, $j);
$problems[$idx]->{'answer'} =
sprintf("%2d x %2d =%3d " , $s, $j, $s * $j);
$problems[$idx]->{'defined'} = 1;
$idx = $idx + 1;
}
$s = $s + 1;
if ($s > $end) {
$s = $start;
}
}
@new = ();
if ($dorand) {
for( @problems ){
my $r = rand @new+1;
push(@new,$new[$r]);
$new[$r] = $_;
}
} else {
@new = @problems;
}
if ($doans) {
printf("\tAnswers: %s\n", $dorand ? "(# $seed)" : "");
} else {
printf("\tPractice: %s\n", $dorand ? "(# $seed)" : "");
}
printf("\tTimes tables from $start to $end.\n");
if ($dorand) {
printf("\tAll mixed up!\n");
}
printf("\n\n");
foreach $x (0 .. 1) {
$idx = $x * (72);
for $y ( 1 ..12) {
if ($doans) {
printf("%s%s%s%s%s%s\n",
$new[$idx]->{'answer'},
$new[$idx + 12]->{'answer'},
$new[$idx + 24]->{'answer'},
$new[$idx + 36]->{'answer'},
$new[$idx + 48]->{'answer'},
$new[$idx + 60]->{'answer'},
$new[$idx + 72]->{'answer'});
printf("\n");
} else {
printf("%s%s%s%s%s%s\n",
$new[$idx]->{'problem'},
$new[$idx + 12]->{'problem'},
$new[$idx + 24]->{'problem'},
$new[$idx + 36]->{'problem'},
$new[$idx + 48]->{'problem'},
$new[$idx + 60]->{'problem'},
$new[$idx + 72]->{'problem'});
printf("\n");
}
$idx = $idx + 1;
}
}
Feeling Marginalized by OpenSolaris
The OpenSolaris project team has elected to leave my favorite shell (/bin/tcsh) out of the default installation media. There is "bug" on this, but I don't think it is getting any traction.
I'm feeling marginalized... it means that when folks first upgrade a system on SWAN to OpenSolaris, I won't be able to login unless they also remember to "pkg install SUNWtcsh". (This also creates a PITA for me on my network, but I've added a secondary user account ... "gdamoreb" with bash as its login shell to my NIS passwd file just so I can work around this.)
Anyway, compared to other decisions that this team has made, I definitely feel "marginalized". Look at some other stuff on the LiveCD:
If you feel the same way, please go ahead and put a comment in the bug report.
I'm feeling marginalized... it means that when folks first upgrade a system on SWAN to OpenSolaris, I won't be able to login unless they also remember to "pkg install SUNWtcsh". (This also creates a PITA for me on my network, but I've added a secondary user account ... "gdamoreb" with bash as its login shell to my NIS passwd file just so I can work around this.)
Anyway, compared to other decisions that this team has made, I definitely feel "marginalized". Look at some other stuff on the LiveCD:
- Not one, but two different e-mail packages (T-bird and Evolution)
- A number of "gnome" games that simply don't work at all.
- Two different versions of "vi" (/usr/bin/vi != /usr/xpg4/bin/vi)
- Unuseful "esd" (enlightenment sound daemon, not used by default)
- A number of not terribly useful device drivers ("pcelx", "pcram", etc.?) I'm going to work on EOF'ing some of these ancient device drivers.
If you feel the same way, please go ahead and put a comment in the bug report.
Friday, October 23, 2009
Call for testers: audioemu10K
I've just posted another update to the audioemu10k package. This update completely redesigned the underlying timing and interrupt support, and as a result it should work better with Suspend/Resume (without getting engine underruns.)
I've posted a webrev as well, and would really appreciate help with codereview.
Additionally, I've fixed the mixer a bit, to the point that I'm confident that a number of devices work perfectly. But some don't. Here's my test results so far:
Thanks!
I've posted a webrev as well, and would really appreciate help with codereview.
Additionally, I've fixed the mixer a bit, to the point that I'm confident that a number of devices work perfectly. But some don't. Here's my test results so far:
- CT4670 -- (Sound Blaster Live!) verified 100% functional, including 4.0 surround.
- SB0100 -- (Sound Blaster Live! 5.1) SPDIF works, 4.0 surround works, no center/lfe output in 5.1 mode. Can't figure out why. (Would love to hear advice on this one.)
- SB0400 (Audigy 2 Value) -- works perfectly. Including full 5.1 surround, SPDIF output. I've not tested the side 7.1 channels because I don't have the necessary cable to do so.
- SB0350 (Audigy 2 ZS Platinum) -- surround sound on rear jacks works fine in 5.1 (can't test 7.1). My expansion box appears to be kaput though (doesn't work in Linux either), so I need help testing this from someone else who has a working one.
Thanks!
Monday, October 19, 2009
test audioemu10k driver posted
I've posted a test package containing the "audioemu10k" driver. (x86/amd64 platforms only).
There is also a webrev with the code.
This driver supports (in theory) a large number of cards from Creative. (Devices identified in prtconf -vp as "pci1102,2", "pci1102,4", and "pci1102,8".) I've not tested many of them though -- only the SB0100, CT4670, SB0310, and SB0360 have been tested, and I've been unable to verify SPDIF or expansion box functionality, but it should work.
To test, you'll need Boomer, which means build 115 of OpenSolaris or newer. I've only tested with build 124, and I recommend using 124 or newer if possible.
If you test it, I'd like to see the output from "cat /dev/sndstat", and as much testing of inputs and outputs (try different mixer controls, as well!) as you can. I'm hoping to integrate this code into Nevada in the next week or so.
There is also a webrev with the code.
This driver supports (in theory) a large number of cards from Creative. (Devices identified in prtconf -vp as "pci1102,2", "pci1102,4", and "pci1102,8".) I've not tested many of them though -- only the SB0100, CT4670, SB0310, and SB0360 have been tested, and I've been unable to verify SPDIF or expansion box functionality, but it should work.
To test, you'll need Boomer, which means build 115 of OpenSolaris or newer. I've only tested with build 124, and I recommend using 124 or newer if possible.
If you test it, I'd like to see the output from "cat /dev/sndstat", and as much testing of inputs and outputs (try different mixer controls, as well!) as you can. I'm hoping to integrate this code into Nevada in the next week or so.
Thursday, October 15, 2009
hme shrinks by about 40%
I just removed about 40% of the code from "hme", by converting it to use the common MII layer. It also makes it use Brussels, and fixes an old bug relating to 10 Mbps functionality. Another net negative lines of code integration for me. I wonder if this confuses ohloh.net's accounting?
Friday, October 9, 2009
OpenSolaris on snv_124 Impressions
I've bitten the bullet, and finally installed "OpenSolaris" over my SXCE install, upgrading from build 105 to build 124 in the process. I thought I'd share some things I've noticed:
- Gnome's volume control Just Works, and doesn't show the legacy Sun device anymore. (Yay!)
- There is a 12 MB Core file on the CD ... er... too big... DVD ... image. (Oops!) Maybe someone was hoping the community would jointly debug the program that generated the core file. (gtk-update-icon).
- Still no /bin/tcsh installed by default. Fortunately easy to get off the network for this machine. (For other systems, not so easy. This really ought to be fixed.)
- AudioHD has a really, really annoying beep on this system. The beep volume control doesn't take effect until you lower it to 33%. (And then it gets really quiet.) This is a bug that I'll have to investigate further, there's probably some codec tweaking needed.
- Regular SunOS vi has been replaced with vim, which has an incredibly obnoxious bug. It doesn't scroll down properly, redrawing on the last line in the terminal window instead of the whole screen. This is IMO at least a P2 bug against the editor. The old editor in SXCE, while maybe lacking some neat colorization features and not being open source, at least worked properly.
- Trying to install CUPS using the package manager GUI fails with a horrible stack back trace. While the request is is made to report the problem with the stack back trace, there is no provision to save it or e-mail it. So alas, I don't have it anymore to post. It should be easily reproducible. (It looked like a problem relating to the SMF configuration.)
Update: Turns out /usr/xpg4/bin/vi (which is what I had in my path anyway) doesn't have this problem. And its installed by default. Yay. But someone really needs to fix vim, because that bug is horrible.
Update 2: When I logged in using my old home dir, the Gnome panel which I had configured for auto_hide did hide itself. But unfortunately would not unhide itself with any mouse actions. The only way I could get it to unhide was to disable the auto_hide property using gconftool2. Unfortunately, it took a while to figure out how to use this.
Subscribe to:
Posts (Atom)