Oh, wait, isn't this the same thing you did to work-around hidden extensions in filenames?
Gee, Microsoft, you could have made filtering network traffic just a little bit more usable. All you had to do was write a log file, or at least give us the option to log what you're doing.
So I'm applying their so-called IP filters to a host before we deploy it. And, unlike some idiots out there in InternetLand, I use a default DENY rule. So, I add one of those. Then I add the exceptions to the "naff off" rule. And then I apply the filter.
And that doesn't work, because now everything is denied. I suppose that's better than having everything allowed, but it's more than a little annoying. Now I have to leave my chair!
The rudimentary firewall in Windows 2000 applies the rules in an somewhat dynamic fashion. In other words, it's unpredictable. If you permit traffic first, and only then deny it, then things work. Maybe. Who knows? It doesn't log anything.
Has anybody else noticed that the release dates and the timestamps on Microsoft's hotfixes don't match up?
bash-2.05a$ ls -ltr *[sSpP]4* -rw-r--r-- 1 wcox wcox 194600 Jul 16 2002 Q320206_W2K_SP4_X86_EN.exe -rw-r--r-- 1 wcox wcox 208360 Jul 16 2002 Q321599_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 234368 Jul 17 2002 Q324380_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 219296 Jul 24 2002 Q326830_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 247488 Jul 25 2002 Q326886_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 337544 Aug 5 2002 q323172_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 871904 Aug 16 2002 Q324096_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 896960 Sep 11 2002 Q323255_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 2750240 Sep 17 2002 Q327696_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 196200 Oct 2 2002 Q329834_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 1194096 Nov 1 17:30 Q329170_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 3836528 Nov 1 20:03 Q328310_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 7590000 Nov 13 20:57 Q329115_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 1435760 Nov 20 18:54 Q331953_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 373360 Nov 21 18:56 Q810833_W2K_SP4_X86_EN.exe -rw-rw-r-- 1 wcox wcox 414736 Mar 14 23:53 Q815021_W2K_sp4_x86_EN.EXE -rw-rw-r-- 1 wcox wcox 2424336 Mar 17 22:42 Q816093_W2K_SP4_X86_EN.exe
Take MS03-010 (Q331953) for example. The page that links to the download notes that the filename is Q331953_W2K_SP4_X86_EN.exe, that the size is 1403 KB, and that it was published on March 26, 2003. Yet the file that I picked up is dated November 20, 2002. And it was signed on Wednesday, November 20, 2002 7:54:21 PM. Does somebody need to synchronize his clock?
I'll hazard a guess that 90% of all corporate e-mail sent is crap, consisting of one-line appendages to massively forwarded posts. Two incremental improvements to existing MUAs could alleviate this situation tremendously:
- selective saving of sent mail
- selective quotation in replies
(On the other hand, since some companies have no idea how to use e-mail effectively, those all-inclusive messages do help to bring one up to speed.)
But the problem I'm concerned with at the moment, because it affects me, is the problem of storage. Now, you could say that storage is not a problem: disk is cheap. However, if purchases are not a solution, and you have to store and backup mail for 185,000 employees, you cap the size of the user's mailbox. What do you do to prevent the quota from being reached?
Do you delete the mail? This has the advantage of removing documents that may become embarassing, unless someone else has stored them in his CYA file. But then you lose a valuable historical record.
Do you move the messages to your local hard disk? The advantage here is that you can devote a larger percentage of that cheap disk space to your mail. But what happens if that disk dies? The probability of an end-user's disk being backed up is effectively nil; that's one reason why mail was centralized in the first place: to make it cheaper and easier to recover from a failure.
Do you extend the quota as the need for space grows over time?
What do you do with paper files? You store them at Iron Mountain for n number of years. Are they automatically shredded? Do you arrange for more space to store those records over time? Why not do that with electronic records? Too much work?
Assume that all of your employees use e-mail. Suppose you allow all 185,000 employees to maintain mailboxes of 150MB or less. If all maximize their quota, you must manage 26.46TB of data. Daunting, no? Since usage patterns vary, not everyone will use all 150MB; however, given enough time, and enough junk mail from HR, everyone will. Time is the enemy here, not space.
One reason for quotas, other than for capacity planning, is to ensure that no single user will prevent other users from using the system. Put broadly, this is the only reason for quotas: to allow time for the system to grow in response to demand. Looking at usage patterns, time is also our ally. Most messages are read and filed once, never to be seen again. The need for them is potential. When that potential is realized, how quickly must the need be met?
It's amazing to me how thin a line there is between "software that tries so hard to be 'smart' that it interferes with your workflow" and "software that does what you tend to want".
He used to have a discussion of the cursor blink rate, but that's no longer there.