Turning_an_ibm_usb_webcam_into_an_ir_webcam

title: Turning an IBM USB Webcam into an IR Webcam date: 2005-05-07 14:23:38

Following the instructions here, I was able to get my $14-at-Walmart-in-Oregon-four-years-ago IBM USB webcam seeing infrared without too much difficulty. Since getting the IR filter out proved to be a bit tricky, and since the note on this camera on Geoff's pages just said "Tricky to find", I thought I'd put up some pix and instructions on how to do this. I'll be curious to see how well it works tonight...I live above a busy street, and I'm hoping I'll be able to get some neat pix.

Tags:

Nice!

title: Nice! date: 2005-05-07 14:39:59

Just came across the Open Source Labs' photo album. There are some pretty funky pictures in there. Oh, and what look like some servers labelled in Braille. Man, I gotta work at a university.

Tags:

If_there's_one_thing_i_can't_stand...

title: If there's one thing I can't stand... date: 2005-05-07 20:13:21

...it's long-haired, shouty, short pregnant people in the streets. I'm totally voting for Lorne.

Tags:

Wireless_link_fast

title: Wireless link fast date: 2005-05-04 05:52:20

It was a duplexing problem, though not like I thought. The radio link in a Tsunami is duplex, and the ethernet interfaces also do duplex, but they don't do auto-negotiation. Setting the interfaces on the computers at each end to 100Mb/s full-duplex worked a treat, and now I'm getting something between 20 and 40 Mb/s -- completely respectable.

Tags:

Wireless_link_up

title: Wireless link up date: 2005-05-03 06:26:30

Welp, the wireless link got set up yesterday. We've now got two Tsunami 100s (unfortunate name, that) installed and pointing at each other from our office windows. Rough guess is that it's something like 150 metres between the two units. OpenVPN worked right away, which makes me happy. Ping times were good between the two units -- 4 or 5 ms.

I tested it by copying the same big-ass file from one end to the other that, over a crossover cable, took less than 2 minutes to copy -- and was shocked to find the ETA listed as 16 hours and climbing. What the...but then I visited the other side and found that the ethernet cable had been connected to the 10Mb/s jack, not the 100Mb/s jack. This made things better, but still crappy: 30 or 40 minutes was the ETA.

Near as I can figure, we're getting about 1.5Mb/s on this thing, which isn't much different from ADSL. The units are half-duplex, and I suppose that could be affecting things somehow (besides the obvious, I mean), but that still seems terribly low to me. I spent most of yesterday getting other things in the new digs working, so I didn't have a chance to call the company who set it up; that'll be today's job.

Another gotcha from the move: turns out that our voicemail system (Norstar something or other) actually requires a phone to be physically present in order to send a call to voicemail after n rings. That was a bit of a surprise. We're currently scrambling to get some extra phones to leave hooked up. (Don't even ask why voicemail or their direct lines doesn't work at the new office.)

Tags:

Some_notes_on_openvpn,_bridging_and_freebsd

title: Some notes on OpenVPN, bridging and FreeBSD date: 2005-05-01 10:55:18

• (This is OpenVPN version 1.6, btw.)
• Bridging can be done pretty easily. Use the device tap0 directive in your config file, then set these sysctl variables: net.link.ether.bridge_cfg: dc2,tap0 -> dc2,tap0 net.link.ether.bridge: 0 -> 1

This assumes, of course, that dc2 is the inside interface you want bridged over the VPN. * If OpenVPN exits for some reason, you need to turn bridging off by setting the net.link.ether.bridge sysctl to 0 before starting OpenVPN again. Near as I can figure, this is because the new tap0 interface is different from the old one, even though it has the same name, because it was created by a different PID. * No problems getting OpenVPN to run under djb's daemontools so far, as long as I toggle bridging as part of the startup script. * On one machine, the inside interface being bridged was sis0, an onboard ethernet interface. This led to worlds of hurt: if OpenVPN went down then started again, everything would look good but the bridge wouldn't work -- I could no longer ping that interface from the other side of the bridge. Furthermore, trying to ping from that machine to the other side of the bridge got me this error: ping: sendto: no buffer space available Googling for this turned up many, many references to this problem. It seems to be a long-standing bug in FreeBSD, present to this day (!) and with no fix (!!), that may or may not have something to do with particular ethernet drivers. I thought I would have to install Linux and rebuild it -- this was on Friday afternoon, and the VPN is meant to be set up this Monday -- but I took a chance and bought some different ethernet cards (Linksys LNE100TX-CA ver 5.1, which in FreeBSD show up as dc(4) devices; thank you, London Drugs) and so far I haven't seen the problem again. * The machine with the problematic sis0 interface is a 2GHz P4; the other side is a 3GHz P4. Both have 512MB of RAM. If I restart OpenVPN on the slower machine, pings take about 30-40 seconds to start working again; if I restart the faster side, it's almost instantaneous. (Both sides know the address of the other side, and both are set to re-initiate the connection if it goes down.) * For testing, the setup is something like this: Client A -- Slow machine -- (OpenVPN here) -- Fast machine -- Client B

Copying a big-ass file from Client B to Fast Machine takes 1 minute; if Client A copies the same file to itself, it takes about 1 minute 20 seconds; if Slow Machine copies the same file to itself, it takes 1 minute 40 seconds; and finally, if Client B copies that same file from Slow Machine to itself, it takes 1 minute 10 seconds. (Copying is done by scp in all cases; Client A and Slow Machine are connected by a crossover cable, as is Slow Machine and Fast Machine; Fast Machine and Client B are connected through by a switch or two.)

Tags:

Holy_crap,_it's_me

title: Holy crap, IT'S ME date: 2005-05-01 12:56:31

A friend of mine sent me this link, and Jesus Christ it looks like me. Family Guy on tonight. Woohoo!

Tags:

DIY, HD

I got the iBook, I got the Slashdot t-shirt, I got the beard...but do you think I can get a wireless signal? Oh no. Thanks, Broadcom. But hey, enough complaining. Time for an update.

The wireless ISP is gonna do a point-to-point link between windows of our old and new temporary offices. Should give us 100Mb/s access or so. Which is good, because for a while I thought I'd have to walk down to London Drugs, grab some Linksys routers, and install my own firmware to do it. Which would have been a lot of fun...but would have been a fuck of a lot to get ready in, like, three days. Now I just have to get OpenVPN talking at either end, get Shaw installed, and set up a firewall. Oboy.

And then there's the troubles I've been having with our backup server. A while back I decided to start racking all the boxes we've been using as servers -- transfer the hard drives to proper servers, then use the old shell as a desktop for a new hire. Welp, the backup server was the first to go, and man it's been a headache.

First off, I didn't take care of cooling properly, and the tape drive (HP Ultrium 215, for those paying attention) suffered a nice little nervous breakdown and kept spitting out the tape. I tried downloading the HP diagnostic tool, but it only runs on Linux and the server runs FreeBSD -- neither Linux compatibility mode (not surprising) nor a Knoppix disk (kept hanging) allowed it to work. So I had no real idea what was going on other than the drive was too hot for my liking.

But HP, bless their souls, came to the rescue. Once I made it through their speech recognition voicemail tree hell, they just sent out another one -- they didn't even bitch about not being able to run the diagnostic tool. Not only that, it came the next day, and we don't even have any special contract with them -- that's just warranty. Thumbs up for them.

But now I've got different problems: the damn machine keeps seizing up on me. See, I've got this 500GB concatenated Vinum array of three disks that I use as a copy of yesterday's home directory for people, and I'm trying to move it to a four-disk RAID5 drive on the Promise array. I tried using rsync, and it just froze...but eventually. I thought maybe rsync was spending too much CPU time figuring out what to transfer, so today I tried using dump | restore -- and sure enough, it froze again.

I plugged in a monitor, hoping for a panic or something, but nope -- just unresponsive. I've found some mention in the FreeBSD mailing lists about possible problems with write caching and the Adaptec 3960D SCSI controller (which I thought was a 39160 SCSI controller, but I guess not). I'll have to see if that does the trick or not -- but in the meantime I'm wondering how I'm gonna get yesterday on the Promise. Of course, figuring out why it's crashing in the first place would be even better...

But it's not all bad news: earlier this week, the support manager at Promise that I've been dealing with called to tell me that the word had come down from on high. Yep...Promise is going to follow the GPL and properly release the Linux and Busybox source code for the firmware that goes into the VTrak 15100. Hurray! I'll have to watch, of course, and make sure it shows up...but it sounds good. "Let's put it this way," said the manager. "It's on my desk for me to do. And I don't want it there for long." To the home front, now.

As if I didn't have enough on the go, I've blown my tax return on the makings of a MythTV backend: 2.4GHz P4, umpty-GB hard drive, the PCHDTV-300 (get it while you can!), generic 128MB Nvidia (no onboard video on this mobo, or I would've stuck with that), a Hauppauge PVR-500MCE, and a nice Asus mobo in an Antec case to tie it all together. Random notes:

1. I like the case-- no sharp edges, very well put together, easy to assemble, and pretty damned quiet. Nice.
2. I think the graphics card was causing problems -- the machine kept seizing up for no apparent reason, and when I opened the case to have a look the heatsink was almost burning hot. (Memory was my first guess, but I'm running Gentoo on this and all the compiles went fine -- kernel, gcc, qt...'as a lotta compiles.)
3. The ivtv project lists the PVR-500 (dual tuners! yeah, baby!) as in alpha, but a fair few people have reported success with it. Me, I'm getting the finest MPEG-2 recordings of static you could ask for...but then, I'm pretty sure I'm doing something wrong, and I simply haven't had a chance to work on it since getting it assembled last weekend.

And now for something completely different: new mottoes for Harley Davidson:

• "Harley-Davidson: Because social contracts are for weak pussy-ass losers with small dicks."

• "Harley-Davidson: Because those other people aren't really human. Not like you and me."

• "Harley-Davidson: You deserve it. So do they."

• "Harley-Davidson: Because if you pissed in their faces, you'd be arrested."

• "Harley-Davidson: Because 'Fuck you!' is just too damned hard to remember."

• "Harley-Davidson: Because 'Fuck you!' is just too damned eloquent."

Tags: backups hardware mythtv vinum rant gpl

Screen_&

title: Screen & date: 2005-04-29 19:36:28

Problem: Screen, installed from ports on a 4-series FreeBSD box, start taking 99% of the CPU (!). Solution: Build from ports. Don't know why I didn't try that sooner. Also: an ampersand ends a command in Bash the same way a semi-colon does. Thus, this is wrong in a Makefile:

all:
        foo & ; \
        bar

And this is right:

all:
         foo &\
         bar

Whee!

Tags:

Promise sends over their MIBS

At last, Promise sends over the MIBs for the VTrak 15100. I've put 'em up with the kernel and busybox sources. Still waiting to hear when they're going to comply with the GPL re: offering source.

Tags: gpl

NWR04B: Why won't it puts?

Still trying to figure out what the hell is going on here, and why it won't print the messages I expect it to (while still printing the FIXME I stuck in at the end of the puts routine w/o any problems). I've been looking at the disassembled zImage, and I'm scratching my head. Here's the deal: shortly after power-on, the decompress_kernel routine is run:

000074 EB000915 BL      &000024D0

In C, decompress_kernel looks like this:

ulg
decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
                  int arch_id)
{
        output_data             = (uch *)output_start;  /* Points to kernel start */
        free_mem_ptr            = free_mem_ptr_p;
        free_mem_ptr_end        = free_mem_ptr_end_p;
        __machine_arch_type     = arch_id;

        puts("EMXIF");
        proc_decomp_setup();
        arch_decomp_setup();

        makecrc();
        puts("Uncompressing Linux...");
        gunzip();
        puts(" done, booting the kernel.\n");
        return output_ptr;
}

At 0x24D0, we've got some initilization, some register saving, and then the puts routine is called:

0024FC E59F0034 LDR     r0, &00002538
002500 EBFFF769 BL      &000002AC

This is the first call to puts: puts("EXMIF"); (which is FIXME backwards; I had it frontwards at first, and wanted to see if the output was any different if I changed the string; it's not). puts looks like this in C:

static void cx84200_puts(const char *s)
{
        while(*s != '\0')
                cx84200_putc(*s++);
        cx84200_putc('F');
        cx84200_putc('I');
        cx84200_putc('X');
        cx84200_putc('M');
        cx84200_putc('E');
}

(more checking to see what works) and like this in ARM assembly:

0002AC E1A0C00D MOV     ip, sp
0002B0 E92DD810 STMFD   sp!, {r4,r11,ip,lr,pc}

Save the registers for later...

0002B4 E1A04000 MOV     r4, r0
0002B8 E5D43000 LDRB    r3, [r4, #0]
0002BC E24CB004 SUB     r11, ip, #4
0002C0 E3530000 CMP     r3, #0
0002C4 0A000004 BEQ     &000002DC

r0 held the argument, and it's moved to r4. Check the first byte to see if it's zero (ie, if we're printing a null string), and jump ahead if it is. Not sure what we're doing with r11 here.

0002C8 E5D40000 LDRB    r0, [r4, #0]
0002CC EBFFFFEB BL      &00000280
0002D0 E5F43001 LDRB    r3, [r4, #1]!
0002D4 E3530000 CMP     r3, #0
0002D8 1AFFFFFA BNE     &000002C8

Load the first byte again into r0, then go to 0x280 (putc) with it. Increment r4 and see if it now points to a zero. If not, go through the routine again.

0002DC E3A00046 MOV     r0, #70
0002E0 EBFFFFE6 BL      &00000280
0002E4 E3A00049 MOV     r0, #73
0002E8 EBFFFFE4 BL      &00000280
0002EC E3A00058 MOV     r0, #88
0002F0 EBFFFFE2 BL      &00000280
0002F4 E3A0004D MOV     r0, #77
0002F8 EBFFFFE0 BL      &00000280
0002FC E3A00045 MOV     r0, #69
000300 EBFFFFDE BL      &00000280

This is the printing of FIXME at the end of puts.

000304 E59F0008 LDR     r0, &00000314
000308 E20000FF AND     r0, r0, #&FF
00030C EBFFFFDB BL      &00000280

Put 0x314 into r0, AND with 0xFF, then call putc again.

000310 E91BA810 LDMDB   r11, {r4,r11,sp,pc}
000314 00042548 ANDEQ   r2, r4, r8, ASR #10

And I think this is where we fall off the end of puts. Finally, a quick look at putc, first in C:

static int cx84200_putc(char c) {
        int i;
        int j = 10;

        CSR_WRITE(UART0_BASE, c);

    for (i= 0; i < 60000; i++)
                ;
}

(j left over from another bit of debugging) and assembly:

000280 E1A0C00D MOV     ip, sp
000284 E92DD800 STMFD   sp!, {r11,ip,lr,pc}
000288 E24CB004 SUB     r11, ip, #4
00028C E3A02CEA MOV     r2, #&EA00
000290 E2822060 ADD     r2, r2, #96
000294 E20000FF AND     r0, r0, #&FF
000298 E3A03209 MOV     r3, #&90000000
00029C E5830000 STR     r0, [r3, #0]
0002A0 E2522001 SUBS    r2, r2, #1
0002A4 1AFFFFFD BNE     &000002A0
0002A8 E91BA800 LDMDB   r11, {r11,sp,pc}

So here are my many bits of confusion:

1. That first call to puts should have r0 pointing to EXMIF, right? Only it doesn't: 0x28A0 is where you can find this string, and r0 points to 0x2538. There's no ASCII there, and certainly no copy of the string I want. If I change the instruction so that r0 points to 0x28A0, the thing crashes badly -- just spews out hexdumps of something (presumably memory).
2. That last call to putc from puts, where r0 points to 0x314. WTF? It explains why I'm seeing H% at the end of the strings, but as far as I can tell it certainly shouldn't be doing that. Again, there's nothing around 0x314 that would explain why we're trying to print it.
3. And in putc, what is with AND r0, r0, #&FF? As far as I can tell, this has absolutely no effect on r0: it's a NOP.

I can only think of three things:

• I'm wrong.
• The disassembler I'm using has a bug.
• GCC has a bug.

If anyone has any insight to share, please let me know. This is really bugging me.

Tags: nwr04b

Argh, Billy.

Less and less impressed with Promise. Here's what I had done: while doing some copying onto a logical drive, I yanked one out. I wanted to see what would happen, what would need to be done, and so on -- I don't want to be figuring this out for the first time when it happens. Well, it started beeping, and the event log said that the logical drive was critical. Start rebuilding, right? Wrong: policy for that drive was set to non-auto-rebuilding. Try turning that on, and it doesn't work: keeps saying it's non-auto-rebuilding. Manual for the VTrak:

if your fault-tolerant logical drive goes offline, go to the Promise website (www.promise.com) and download a document calledArray Recovery Procedure.

Damn good thing I'm not doing this for real. Go to www.promise.com and type "array recovery procedure" into the search bar. The result:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot use a CONTAINS or FREETEXT predicate on table 'product' because it is not full-text indexed. /search_insert_eng.asp, line 34

Fuck me. Use Google to find the document, which has instructions for the UltraTrak, the predecessor to the one I've got. Hope it still applies and read on. It sez to reboot the array (!) in order to trigger the rebuild (!!). Sure enough, it works. Oh, and have I mentioned they still haven't sent me the SNMP OIDs/MIBs after six weeks of calling their technical support manager? FUCK ME.

Tags: hardware

NWR04B: It's crashing!

I'm starting to make a bit of progress on the NWR04B -- almost to the point where I could comfortably say it's crashing. Yay! The problem so far has been that I wasn't getting any output on the serial port when (presumably) Linux was booting. Some judicious insertion of ARM assembly code into the kernel image showed me that it was at least running, but I had no clue what I was doing after that. I managed to follow the path of the assembly code through head.S, which is the very, very first bit of anything that gets run when you've got a compressed kernel. This is so early that it takes a while even to get around to decompressing the kernel. After that, I was able to follow it through to misc.c, where decompress_kernel gets run. There's some puts statements in there (like puts ("Uncompressing Linux...");), so how come I wasn't seeing anything? Well, because puts wasn't defined as anything. puts is defined in head.S as some assembly code to write a string to the serial port, but that wasn't referenced by misc.c; attempts to #include it failed horribly. There's an #ifdef STANDALONE_DEBUG that defines puts as printf, but attempts to build a kernel using that didn't work either. But follow the bouncing ball:

• arch/armnommu/boot/compressed/misc.c #includes asm/arch/uncompress.h
• which is actually include/asm/arch/uncompress.h
• which is, once you follow the symlinks, include/asm-armnommu/arch-cx84200/uncompress.h
• which defines puts as cx84200_puts
• and uncompress.c defines that as being an empty function
• but the equivalent definition in arch-samsung defines it as a bunch of calls to putc``
• and that is defined as CSR_WRITE(DEBUG_TX_BUFF_BASE, c)
• so the equivalent for arch-cx84200 would be CSR_WRITE(UART0_BASE, c)
• because UART0_BASE is defined in hardware.h as 0x90000000
• which I knew from reading the datasheet is the chunk of memory where you drop stuff when you want it written to UART0, aka serial port 1.

Whew! So I tried that, and hey -- I got garbage on the screen! But not very much: I was expecting something like "Uncompressing Linux..." and instead got maybe 20 characters of garbage. I took another look at the assembly version of puts, and one of the things it does is waits for 20,000 clock cycles -- which at 60MHz is a third of a second. Try adding a loop to count down 60,000 cycles (what the hell), and hey! more garbage -- though still a finite amount, and it stopped after maybe 5 seconds or so, and still nothing intelligible. What the hell's going on? I tried this:

static void cx84200_puts(const char *s)
{
        while(*s != '\0')
                cx84200_putc(*s++);
        cx84200_putc('F');
        cx84200_putc('I');
        cx84200_putc('X');
        cx84200_putc('M');
        cx84200_putc('E');
        cx84200_putc("\n");
}

and now I started to get garbage that had FIXME tossed in for good measure. A quick cat /dev/ttyS0 > logfile (have I mentioned that I love Unix?), and whaddaya know: I'm getting precisely four FIXMEs. If I threw an extra puts ("FIXME"); into misc.c, I got five, not six -- the string going to puts doesn't come out, but the extra putcs I put in do work. For the moment, this is where I'm stuck. The garbage/extra characters I'm seeing don't seem to have any relation to messages I might expect ("FOO", "Uncompressing Linux...", etc. There's places for the kernel to crap out after that, but I don't think there's any before. And why the hell am I seeing all the garbage, then a perfectly intelligible "FIXME" after that? What is happening to the strings to get them all fucked up?

Tags: nwr04b

Daisy, Daisy, give me your patches, do

Holy crap, I'm busy these days. First off, it's MS patch week. That means I'm in here on a Saturday afternoon patching by hand. Yes, you're right, it's very ugly; this is why I'm trying out a couple of things that I hope will make it easier. The first is Daisy, a program (and by the way, the next time someone says "solution" when they mean "program" ah munna punchem inna cock) from the University of Virginia Virginia Tech (thanks, Joe) that

• automates Windows patches, and
• is Free Software. Yay!

It has a couple problems that seem mostly due to the program they use to scan for missing patches -- always seems to say that the same three patches are needed, whether or not they've been applied -- but overall I'm quite happy with it.

The next thing I'm trying is running Daisy remotely, by installing Cygwin and SSH on each of the machines. Unfortunately, this isn't working so well; the same command-line options that work from a local shell (whether Cygwin or cmd) just don't when I'm logged in by SSH: it says that it can't see that any patches have been applied, tries to download 'em all from the local repository I've set up, and is very unhappy when they're not there.

Next thought is to try installing crontab and shutdown with Cygwin and use crontab to run Daisy (or other patches) locally. That has problems too: Cygwin looooooves updating everything, and if you've (say) installed Cygwin a year ago and haven't bothered updating it since, it runs around trying to download newer versions of everything. What's more, there's no way to turn off that behaviour in the installer...very annoying. I think I'll try installing crontab and shutdown individually (managed to find a script a while back to do that properly), and see how it goes. Of course, since I've just applied all the patches for this month, it's gonna have to wait.

Which is fine, because second, I found out on Thursday that a dozen people are moving to a temporary office for two months, they'll be there May 2nd, and I have to make sure they can still work while they do that. A bunch of them are doing nightly regression tests; this means their files will need to be here, but a 1Mb/s cable link and X forwarding is gonna be mighty painful. (Or so I'm told...why they can't just use SSH and vi for everything is beyond me...grumble...)

I called around to see if anyone could set up a temporary LAN extension over fiber or some such, for two months, with two weeks' notice. HA! Not a chance: a six-month contract and a six-week lead time was the best anyone was willing to offer. But hey, not a problem -- the new place is maybe 150 metres away as the crow flies, and we've got line of sight in between here and there -- hell, I can see the corner office from here.

So I called up Telus and asked them if they could do this. "Sure can!" said the bright young man I was dealing with, and you could hear the wind from his enthusiastic nodding. "We'll do 802.11g between here and there. It's perfect! And it only takes 8 weeks to do a site survey!" I reminded him of my two week deadline. "Not a problem! We'll just convert it after the move to wireless Internet access over your entire office! The boardroom, the desktop, the kitchen...and we remotely monitor it to prevent intrusion! We'll use whatever authentication standard you're using! We try to stay away from WAP, but we can use WEP if you like!" Sigh...okay, how much? "Forty-five thousand dollars. How soon do you think you'll be able to take advantage of this opportunity?"

Fortunately, I found another ISP that's interested in mounting an antenna on the roof just to be able to offer their service to other tenants. Looking good so far. And since they offer gigabit Internet access for $500/month, I'm thinking the price can't be that bad. (Yeah, gigabit 'til the first router that isn't theirs. But still.)

Third, I'm still trying to get the Promise VTrak up and running here. Still running out of space, still haven't had much time to play around with it. Well, except for today. Starting to find a couple things that are annoying (besides the GPL violations, I mean). First off, it looks like changing the cache policy on a logical drive (ie, from write-through to write-back) requires a reboot of the array itself (!) to take effect. Second, even without changing the write-back policy, it looks like a reboot of the array makes a newly-created logical drive orders of magnitude faster -- ie, bringing it up to an acceptable speed. (I'm not certain of that, though, so grain of salt etc.) Third, no MIBs/OIDs -- whatever the proper term is -- for SNMP are shipped with the documentation...still trying to get this out of Promise.

Tags: windows

Took a while...

but I was finally able to track down the original for this picture. It's absolutely amazing...just like this and this. Strange how you change. I used to read and re-read Huckleberry Finn 'til I wore out my copy, wishing I could've lived in 19th century America. Now I'm afraid I (or my species) won't live long enough to get into space, and wish I could be part of some grand colonizing effort.

Tags: space

More_work_on_the_promise_vtrak_15100

title: More work on the Promise Vtrak 15100 date: 2005-04-17 07:46:59

I don't know what I did right, but I've had a lot more luck with the Promise VTrak 15100 this time. I got a chance to work with it more on Monday, and this time it just worked.

For the record, what I'm using for testing is a P4 running FreeBSD 4.10, an Adaptec 39160 card, and the VTrak with 4 disks. I had set them up in one RAID 5 array on Saturday, and was unable to see the disks at all. This time, I deleted that array, created a new RAID 0 array of one disk, rebooted FreeBSD, and bam -- da0 was right there in dmesg.

I set up another RAID 5 array of three disks, ran camcontrol rescan all, and there was da1. Very strange.

Strangeness continued: the two disks were sloooooow when I first used them. The first array was about 250GB, and the second was 450GB; running newfs took 7 and 14 minutes__, respectively. To make sure it wasn't something specific to formatting, I ran dd if=/dev/zero of=/mnt/test bs=100m count=100, and the times were similarly ridiculous: between two and three minutes, compared to 2-3 seconds on a local, IDE-based drive. WTF?

I decided to reboot the VTrak, and the problem went away: the dd test took about 3-4 seconds...slower than a local IDE drive, but acceptable. Still no idea what might've been going on.

Tags:

Amd_and_aliases

title: amd and aliases date: 2005-04-12 06:19:05

Weird problem yesterday when moving a server: for some reason, amd would not start up properly when it rebooted in its new location. Same network setttings, same chunk of network, so wtf?

ps showed that its terminal was con -- console, I presume -- which was doubly weird. I logged into another machine to make sure that was abnormal, and yes it was. amq -f gave the error program not registered, and sure enough rpcinfo -p showed the usual suspects sans amd.

Well, the only thing different about this machine is that it's got some jails running (which don't need to be running anymore, but I hadn't had a chance to shut them down). That meant some additional aliases for its outside interface in /etc/rc.conf on the subnet I set aside for this sort of thing. I commented them out, rebooted, and presto -- no more problems. Maybe something to do with picking which interface to listen on?

Tags:

Is_it_safe?

title: Is it safe? date: 2005-04-12 17:47:54

Is it safe?

Tags:

Captcha != Turing Pass

Yet another person confusing the presence of a graphical browser with passing the Turing test. O'Reilly's articles are usually excellent, which makes even more confusing the lack of any mention of text browsers or the disabled. Yo, Tim! You listening?

Tags: rant

headdesk headdesk headdesk

From the article Fewer permissions are key to Longhorn security:

Microsoft said it would encourage the use of least permissions in Longhorn by making it easier for users to do common tasks without administrator privileges. For example....allow developers to create per user installations of applications, with user-specific settings saved in the "my programs" folder, rather than a globally accessible program files directory that requires administrative permissions to change....Windows programs commonly save user-specific files to critical areas of the operating system, such as the program files directory or protected parts of the Windows registry, which stores configuration information and is off-limits to regular users...

...splutter...Gee, individual settings saved in areas controlled by individual users...WHY IS THIS NEWS? How is it even possible that this never occured to MS before?

The company also has an opportunity to brand LUA with its own user-friendly features and interfaces, which would be a vast improvement over platforms like Sun Microsystems's Trusted Solaris and Unix, Gartner's Pescatore said. "They are so complex, nobody can use them," he said. "They require every user to be a security expert. But if you look at what Microsoft is good at, it's not inventing ways to do security, but ways to make security easier to implement for security administrators."

Okay, WHAT? What the fucking fuck was that? Have I been trolled? Is this guy secretly laughing up his sleeve at the way my face is turning RED WITH RAGE? Honestly.

1. Where the fuck was Microsoft when they were writing NT/2000/XP? Why the hell are there so many fucking programs that demand admin or power user access simply to use? No, MS did not write all these programs themselves, but it's their damned operating system and their damned culture of "Well of course you're the only one on the computer! Of course you're running as a power use! Of course it won't affect anyone else if you're given too much privilege!" Microsoft has a LOT of shit to clean up, and it's not just in their crappy, crappy OS: it's in the attitudes passed on to users and developers too.

2. "[Solaris and Unix] require every user to be a security expert." No, actually, they don't. That's the whole fucking point. The programs are (generally, yes there are exceptions) well-behaved: they don't need crazy privilege, they save user-specific files IN THE USER'S FUCKING DIRECTORY, and so on. You need one security expert -- the sysadmin (and hey, before anyone kicks I am not saying I'm a security expert or anything like it) -- who sets things up safely. You don't have a glorified text editor (hello, Code Composer!) that requires power user to run it, and you don't have the accompanying conversations about "please don't install that app again".

3. "But if you look at what Microsoft is good at, it's not inventing ways to do security, but ways to make security easier to implement for security administrators." HA! It is to laugh. I can hear you out there wondering why I don't get a copy of Regmon to look at what registry keys CC needs access to, and open up the permissions on that. Excellent question, and I should be dropping everything to do that right now -- point taken. But why the fuck isn't a tool like this included with 2K to start with? Why are all the admin tools MS does provide squirrelled away in different resource kits and download areas, safely kept from the unschooled likes of me?

I'm ranting. There are flaws in my arguments. I don't like or trust MS or Windows very much. I lhave drunk deeply of the Unix kool-aid, and I am horribly, horribly biased. But for the love of all that is holy, this whole article just leaves me agog. Redmond can't be that ignorant, and I mean that sincerely. But what the hell else am I supposed to think? Why has twenty-five years of open, easy-to-find operating system knowledge passed them over? What lamb's blood did they smear over their cubicle doors to prevent the Angel of Death from entering?

(Story hit Slashdot today, and I saw it too late to get this comment in...so this rant hits the journal. You lucky, lucky people.)

Tags: rant