2008-06-17
A simple request for vendor websites
Dear vendor websites, I have a simple request for you, or more specifically for your search people: there should be a search box where I can plug in either a product name or a part number, and the first thing that comes up should be that product's or part's webpage. This should work even for parts that you don't normally sell separately, and it definitely should work for the product codes that you put on your boxes. In specific, I should be able to take a mysterious box from you (perhaps containing rack rails), punch its cryptic code into your website, and find out exactly what it is and what it goes with.
(I do not mind if this is an advanced search option, just as long as there is an obvious path to it from basic search. But it really should be part of your basic search, because it's not going to be often that people enter a product name or part number and want something other than the product's page.)
Doing this sort of a smart search engine is one of the few ways that you can do a better job of search than Google can, because you have domain specific knowledge. Conversely, if you cannot manage to do this you might as well outsource your entire website searching to Google anyways, because your search technology and your search interface are both likely to be worse.
(If you must override Google's results for specific queries, there are ways to do that while still using Google for most everything. But if you are overriding queries to start with, you can perfectly well do this too.)
Unfortunately I do not expect the current depressingly bad situation with vendor website search to get better any time soon; vendors that actually do a good job of this are, to put it one way, extremely uncommon.
(This entry is brought to you in part by the fact that we turn out to have quite a lot of female to female DB9 null modem cables, because Sun gives you one with each X2100 M2. They just don't tell you what the cryptic connector is, so in the end I had to use a pair of paperclips and a multimeter to find out.)
Sun flubs another SSH patch
I haven't been involved with Solaris 9 for a while now, so I have no idea if they've fixed the Solaris 9 SSH patch problem by now (although I certainly hope they have). But I was recently heartened to discover that Sun is perfectly capable of fumbling Solaris 10 SSH patches as well.
Sun recently released patch 126134-03, 'sshd patch', for Solaris 10 x86, in order to fix CVE-2008-1483, where the fun semantics of IPv6 versus IPv4 let an attacker hijack forwarded X sessions. Unfortunately if you install this patch on a system without IPv6 enabled, you lose the ability to forward X at all.
(Instead, sshd syslogs the message error: Failed to allocate
internet-domain X11 display socket. What it really means is that it
failed to allocate any IPv6 listening sockets because you don't have
IPv6 enabled, and it refuses to fall back to IPv4.)
It is difficult for me to understand how Sun managed to screw this one up. The bug is not unique to Sun's version of SSH and other operating systems managed to get the fix correct, and the problem is uncovered in literally ten seconds of testing on one of the most common customer configurations of Solaris 10 x86. Somehow Sun either let it slip through anyways or decided that it didn't matter and they would release the patch with known issues and without any sort of warning (and I am not sure which option would be worse).
Unfortunately, there's a bigger issue here than Sun continuing their history of screwing up ssh; it is that this makes it clear that you cannot trust Sun security patches. Untrustworthy security patches are only slightly better than no security patches, and arguably they're worse; at least with no security patches you know clearly where you stand.
PS: if you want workarounds, the ones here might work.