07 May 2005
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:
07 May 2005
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:
07 May 2005
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:
04 May 2005
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:
03 May 2005
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:
01 May 2005
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:
01 May 2005
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:
29 Apr 2005
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:
- I like the case-- no sharp edges, very well put together, easy to assemble, and pretty damned quiet. Nice.
- 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.)
- 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
29 Apr 2005
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:
And this is right:
Whee!
Tags:
21 Apr 2005
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
21 Apr 2005
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:
- 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).
- 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.
- 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
19 Apr 2005
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
17 Apr 2005
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
#include
s 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 FIXME
s. 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 putc
s 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
17 Apr 2005
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
17 Apr 2005
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
17 Apr 2005
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:
12 Apr 2005
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:
12 Apr 2005
title: Is it safe?
date: 2005-04-12 17:47:54
Is it safe?
Tags:
08 Apr 2005
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
08 Apr 2005
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.
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.
"[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".
"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