My concern with the digital billboards that I have seen is they add to the
light pollution
of the
nighttime
sky. In the silicon valley we have two on 101 (Redwood City and Santa Clara) that spew photons across the spectrum at a glaring rate.
If ClearChannel is going to insist pushing these digital billboards with "time of day" related messages, then I hope they will turn down the brightness of their billboards at night as well.
Hosting your own DNS server allows you to
have full control and maximum
flexibility over your domains.
But don't forget that you need an
off-site secondary DNS server as well!
You need a secondary DNS in case your site
is cutoff from the net
(backhoe cuts your cable), or if your ISP has
routing/service problems, or if you suffer
a loss of power for an extended period of time.
Loss of DNS service is more than people
simply not being able to reach your site, loss
of DNS service means EMail bounces (servers
return EMail if they can no longer resolve
your domain).
Loss of DNS service means that web browsers
tell your customers that you do not exist
instead of simply telling them that you are
down / not responding.
You want a secondary DNS that is located
"elsewhere".
You want it far enough away that a single
regional disaster (power outages, floods, earthquakes, etc.) does not take out both
your primary DNS and your secondary DNS.
You want your secondary DNS to have a
distinct set of service providers to
increase the chance that sites will be
able to resolve your domain if the
regional network is partitioned.
Run your own primary DNS.
Make it a non-caching, non-forwarding,
static, only answers queries for the
domains it is authoritative.
Then pick 1+ secondary DNS services that
will slave off of your DNS master keeping
in mind the points raised above.
One example of a secondary DNS Service is
BackupDNS.
They are inexpensive:
Secondary DNS hosting your 150 domains would
cost $28.50 US
per month ($0.19 US per zone per month).
They let you be in
full control of your DNS service:
Their site lets you new add zones,
update (purge your
zone on their servers and then force an reload)
or remove zones on the fly.
They will be a backup MX site if you like.
They can even grok TSIG to improve the
security of zone transfers.
The
BackupDNS
folks are clueful, efficient,
reliable and (unlike NetSol/Verisign) non-evil.
I'm sure there are other secondary DNS Services
that are both clueful, inexpensive.
I mention these folks because we have had
years of flawless secondary DNS service from
them.
To sum it all up:
Run a primary DNS to maximize the control
and flexibility
over your own domains.
Use a clueful off-site secondary DNS service to
maximize the chance that others will be
able to resolve your domain.
While you are
waiting to install the new kernel code code,
you might try a filesystem
mount option called noatime
that has been in many *n*x distributions
for a while now.
If you don't care about last access times on
your files, then you should consider mounting
your filesystems with the noatime mount
flag as in this/etc/fstab line:
LABEL=/blah/blah ext3 defaults,noatime 1 2
Reading a file under noatime means that
the kernel does not need to go back and update
the last access time field of that
file's inode. Sure, multiple reads over a span
of a few seconds will only cause
the in-core inode to be modified, but eventually
that modified inode must be flushed out to disk.
Why cause an extra write to the disk for a
feature that you might not care about?
For example:
think about those cron jobs / progs that
scan the file tree (tmpwatch, updatedb, etc.). Unless you mount with the noatime option,
your kernel must at least update the last
access time fields of every directory's
inode!
Think about those/etc files that are
frequently read (hosts, hosts.allow, DIR_COLORS,
resolv.conf, etc.) or the dynamic shared libs
(libc.so.6, ld-linux.so.2, libdl.so.2, etc.)
that are frequently used by progs. Why
waste write-ops updating their last access
time fields?
Yes, the last access time field has some
uses.
However, the the cost of updating those last
access timestamps, IMHO, is seldom worth
the extra disk ops.
There are other advantages to using the
noatime mount option... however to
wind up this posting I'll just say that I
always mount my ext3 filesystems with the
noatime mount flag. I recommend that
you consider looking into this option if you
don't use it already.
''*Is* there even a proper name for "5 million trillion trillion"?''''
You can find the name for "5 million trillion trillion"
== 5e30 by using my
English
name of a number, an open source Perl program that
can generate names of numbers of any size
(e.g., the English name of the
largest
known prime).
In the above article, one could replace ''5 million trillion trillion pounds'' with:
five nonillion pounds in the so-called
American system
five quintillion pounds in the so-called
European system
And one could replace ''10 billion trillion trillion carats'' with:
ten decillion carats in the so-called
American system
ten quintilliard carats in the so-called
European system
In the state of California, supermarkets are required to
give you the option of obtaining an anonymous
discount card. I know this because when I was an
elected official, I worked with my regional state legislators
to draft and pass the legislation.
Any retail or wholesale discount card that is not a line of credit,
nor an instrument of debt (e.g, debit card) cannot
require the consumer to disclose ANY
information. They cannot even require you to provide
your name! They cannot tie the use of a financial
instrument (such as a credit, debit or check) back
to the discount card account. Lastly, any consumer may
lend or give their discount card to anyone else.
You can use your discount card, hand it to the next
person in line and apply for a new card the next
time you come into the store if you wish.
At my California supermarket, at the bottom of the
form there was a small box that says "I decline to
provide any information". When I received my discount
card application I quickly went to the very bottom,
checked the box and immediately handed it back to the clerk.
They clerk was clearly puzzled, but with a little
prompting I managed to convince them I and
completed the form and so I got my first card.
Then to demonstrate the anonymity, I gave my card
to the next person in line who didn't have a card.
I'm currently using a card that I friend from out
of town picked up (who also checked the box) and
gave to me.
Some supermarkets have been slow to update their
application forms, even thought the California law
started 1-Jan-2001. I have had to help a friend deal
with a supermarket who didn't want to give him a
anonymous discount card. A call to the
HQ of that supermarket cleared up the matter.
(BTW: The store's excuse was that they had
printed too many of the old forms that required
comsumer information to toss them. Lame!)
Perhaps the California law needs to be changed
to prohibit the stores from even asking for
such data?
So I won't be notified of a beef recall anytime soon.
Not that I care. I'm a vegitarian.:-)
According to mission manager Jennifer Trosper at
the end of their 1810 UTC (22 Jan 2004) news conference:
"
If the spacecraft believes it's in a fault mode, its command rate should be 7.8 bits per second. We sent a beep today, this morning, about the time that we came down here to talk to you. We sent a command that says if you get this send us a beep. And I'm told from Richard that Jennifer came down here to tell us that they think they got it! That would tell us that the spacecraft thinks it's in the fault side of the tree some how for some reason. That would mean that we have got positive power, some elements of the software is working, once again the Xband system is working... the SSPA, the multispace transponder, all that stuff is working so that would be more information.. good news. We need to confirm that. Data off the DSN sometimes needs double checking. We'll let you know if that's for sure."
While the buildup on this filter is not good, it
is does not signal the "beginning of the end"
of the mission as some have suggested.
The problem only shows up with only one filter at
the lower end of the filter's spectral range.
The amount of buildup and its effect on
various frequencies has been measured.
There is even a model for how the buildup has
increased over time.
A review of older data and instrument calibration
may be able to further validate and refine this
buildup model.
In most cases old data that used this filter
can be corrected to a reasonable degree.
In nearly all cases, this buildup has a nil
impact on the scientific conclusions that
have thus far been produced.
NASA is examining a potential correction
to the buildup.
They are considering what is known as a
"bakeout": going through a warm-up
and cool-down cycle to boil off the contamination.
They are going through a risk / reward analysis
at the moment.
The reward of a buildup reduction is being
compared to the risk that the bakeout will move
the contamination to other instruments.
It is possible that the bakeout will happen in
mid December, or it will be moved
from mid-December to a later date
or canceled altogether.
So while the buildup is not good / unfortunate,
it appears to be neither fatal nor mission threatening
at the moment.
P.S. To those who asked about the using the
remaining on-board fuel to lower the bottom of
the orbit to a shuttle serviceable level.
The remaining on-board fuel is insufficient to
do that... a rough calculation shows that it
is 1-2 orders of magnitude too small.
While I feel sorry for those who are innocent victims of
blacklists, I cannot also ignore the most of
the spam comes from a only few IP addresses.
Over the past 6 months, some 65% of spam (and
spam attempts) that my ISP received came from
less than 0.16%
of the assigned IPv4 address space.
Almost 2/3's of
the spam we saw was sent over SMTP connections from
one of 77 CIDR blocks (ranging from/16 to/30 in size).
These 77 CIDR blocks represent less than 1/6 of
1 percent of the assigned IPv4 address space.
BTW: The CIDR list growth factor is not much
when you move from the 65% level to the 90% level.
... your stats may vary.:-)
Spam is truly a world wide problem.
Those 77 blocks, by national/region, break down as follows:
1 Australia
1 Belgium
8 Brazil
1 Canada
8 China
3 Dominican Republic
1 Spain
1 France
1 Israel
1 Italy
1 Japan
15 Korea, Republic of
3 Mexico
1 Poland
1 Russia
2 Thailand
3 Taiwan
25 US
The above list is provided for the curious.
I do not recommend that people block IP
addresses based on the hosting country.
"Yes, Virginia", a few IP address blocks
do transmit most of the spam.
* 1 (purchase an product or renew an exist product)
* then 7 (all other questions)
I recommend that you be patient with the Verisign rep that answers the phone. That person may not fully understand the issue / problem, and they are unlikely to personally be responsible for the Verisign decision. Remember that you are objecting what Verisign as a company is doing. Don't yell at the rep. Be polite but firm.
Ask Verisign to stop the wildcarding now. Explain why what they are doing is wrong (such as being unable to determine of a EMail message is being sent from a bogus / non-existent domain because thisdomaindoesnotexist.com resolves to 64.94.110.11).
If you do business with Verisign now, tell them that you will switch vendors unless Verisign stops this practice in X weeks. (fill in the X)
You might want to leave your phone number and request a callback. Anonymous complaints do not go as far.
If you are in the US, you might want to contact your local member of congress and object about what Verisign is doing. Let Verisign know that you are doing this when you call.
Yes, they might flush your complaint down/dev/null. But I suspect that pressure from all fronts might help. I have been told (off the record) that some people within Verisign are not happy with their wildcarding. Complaints get logged into a database that these people can review. Your complaints, in volume, might help those folks make a stronger case against top-level wildcarding.
I recommend that you be patient with the Verisign rep
that answers the phone.
That person may not fully
understand the issue / problem, and they are unlikely to personally be responsible for the Verisign decision.
Remember that you are objecting what
Verisign as a company is doing.
Don't yell at the rep.
Be polite but firm.
Ask Verisign to stop the wildcarding now.
Explain why what they are doing is wrong
(such as being unable to determine
of a EMail message is being sent from a bogus /
non-existent domain because thisdomaindoesnotexist.com
resolves to 64.94.110.11).
If you do business with Verisign now, tell them that
you will switch vendors unless Verisign stops
this practice in X weeks. (fill in the X)
You might want to leave your phone number and
request a callback.
Anonymous complaints do not go as far.
If you are in the US, you might want to contact
your local member of congress and object
about what Verisign is doing.
Let Verisign know that you are doing this when you call.
Yes, they might flush your complaint down/dev/null.
But I suspect that pressure from all fronts might help.
I have been told
(off the record) that some people within
Verisign are not happy with their wildcarding.
Complaints get logged into a database that these
people can review.
Your complaints, in volume,
might help those folks make a
stronger case against top-level wildcarding.
I picked up my
Honda
Insight Jan 20, 2001.
Oh, the irony of picking up a ultra low mile car when a
pair of Oil-men in Washington DC were... !!!
I have been very happy with the car.
Great mileage:
You can drive it like a j-random
normal 5-speed can and get about 63.5 MPG
(3.7 L/100km).
With a little practice and
following some
standard
tips
you can get a lot more.
I usually get about 750 miles to 900 miles (about
1200 km to 1450 km) on
a 11 US gal (41.6L) tank
(68.1 MPG to 81.9 MPG == 3.45 L/100km to 2.87 L/100km).
Good pep: Pushed 108 MPH on a test track.
Could have gone a bit higher but test track
conditions were not the best.
(Hint: your mileage suffers at that speed,
so I don't recommend it that fast:-)).
More than enough zip to make it onto a
freeway with a short on-ramp.
Fun to drive.
I love the idle stop feature (engine turns off
under certain conditions).
The digital display panel is well designed
and can give you good feedback (out of
the corner of you eye) what works
People really notice it, even after 2+ years.
When gas prices in California push their
way towards $2/Gal (and beyond:-( ), I
start to get a lot more people asking about it.
Does the National Do-Not-Call List only cover
human voice / recording sales pitches or does it
also cover "telemarketing" FAXes?
I know there are laws covering junk FAXes.
I'm wondering if your
FAX is on the Do-Not-Call List and you receive a
junk FAX on it, then can you also go after the junk FAXer
for violating the Do-Not-Call List?
The first legal fight over an GPL happened in 1989.
Amdahl attempted to declare that they owned SMail v3
and did not have to ship SMail v3 source even though:
one of the authors, when they came to work
at Amdahl, listed SMail as prior work in his inventions
and disclosures form
SMail v3 (sharing no code with SMail v2)
was a completely new code base that
was created under the GPL
an important Amdahl customer requested that
Amdahl ship SMail as part of their product, and
did so knowing that SMail was under the GPL
a director, with the concurrence of the VP, approved
our working on and contributing to SMail, under the terms of the GPL
Thanks to the support of
John Gilmore
and a very good lawyer, the case was resolved before
we went to court.
In the end,
people were allowed to obtain source for the version
of SMail that Amdahl shipped,
and Amdahl agreed to follow the terms of the GPL
(for SMail and any other GPL-ed code) from then on.
Both RHAT and SCOX fell during in the dot-com crash.
SCOX fell a little deeper and
then has recovered a bit making their 2 year
numbers appear a bit better than normal.
RHAT held its value somewhat during the
that same period.
From the stock report SCOX fundamentals
appear better than RHAT.
On the other hand SCOX stock risk appears to be
much higher than RHAT.
The Consensus Recommendation on SCOX
over the last few years has been from
weak hold to sell.
Currently there is no consensus on SCOX.
The Consensus Recommendation on RHAT
over the last few years has been from
weak hold to buy.
Currently the consensus ranges between
a hold and a strong buy for RHAT.
For the record: INACFP (I am not a certified
Financial Planner).
On the news of RHAT's
lawsuit, I purchased some RHAT stock.
You should carefully read the prospectus
and research the stats
of any company before trading it.
If needed, seek professional advice
before acting on any stock advice.
As one of the people who helped restore the
Enigma machine at the History Center, I can
attest to the fact that it is genuine.
A few years ago, the
donated Enigma machine was not in working
order. It took a several work sessions
to get it operational (cleaning, wire
repair, replacement bulbs (of the same
type and era), switch repair,
etc...) The machine lacked 2 of the 5
rotor types, so another member did a
lot of hard leg work to get a loan of
some authentic rotors from a TLA.
The Enigma is a bit cranky. The mechanical
contact switches in the keyboard need to be
cleaned more often and one might guess.
The Enigma is not very ergonomic either...:-)
We used that Enigma machine to encrypt a real
message that was known to have been broken
by the folks at Bletchley Park. Some 60 years
ago, their code cracking machine took ~2h 45m
to search about 1/2 the key space (during
which several false positives turned up)
before the real key was found. Turing's
algorithm, ported to a stock Cray 1, took
30 seconds to find the same key.
The Cray 1, designed in the mid 70's, was
only 330 times faster than the special
purpose Bletchley Park code cracking complex.
That 1940's technology used at Bletchley Park
was truly amazing for its time.
p.s. Not only does the Computer History
museum have a Cray 1, 2 and 3; it has
one of every major model that Cray
designed going way back to his early
CDC days and his special Navy machine.
Perhaps the following comments will help
you understand how my Perl filter example
protects terminal emulators... even
terminal emulators that are
subject to the kind of attack
discussed in the referenced article.
Lines such as:
$line =~ s/... some common phrase you want to ignore...//;
next if $line =~ m{... etc...};
serve as part of the ''removes certain types of messages'' processing.
And lines such as:
$line =~ s/... some field you want to ignore...//;
$line =~ s/... some common phrase you want to ignore...//;
serve as part of the ''removes certain types
of... fields'' processing.
And lines such as:
$line =~ s/^(.{1,224}).*$/$1/;
serve as part of the ''trims to 224 characters'' processing.
And lines such as:
chomp $line;
...
print "$line\n";
ensure that each message read is printed with
a trailing newline.
To protect terminal emulators,
the following lines are used:
$line =~ s/\t//g;
$line =~ s/[^ -~]/~/g;
For systems using ASCII (and a number of
other widely used character sets), it
replaces potentially dangerous characters
with ~ (tilde) characters.
The replacement is 1-for-1, so the layout
of the original message is mostly preserved.
I say ''mostly preserved''
because a tabs are replaced with space.
I prefer to view whitespace as just token
separators and to reduce them where
reasonable.
A more complete whitespace crusher would use:
$line =~ s/\s+//g;
$line =~ s/[^ -~]/~/g;
On the other hand, you might want to keep
all whitespace as it is when tailing log
messages in your terminal emulator window,
so:
$line =~ s/[^\s!-~]/~/g;
would do the trick.
And of course one could write the regexp
to not depend on a character set order.
I'll leave that exercise up to the reader.:-)
BTW: I prefer to replace strange characters
instead of tossing them.
Tossing strange characters instead of
replacing them could would allow a system
cracker to potentially mimic a valid
messages knowing that invalid chars would
simply be tossed.
And I usually want
to know when strange chars appear
in the logs.
My terminal emulator windows happen to use a
font that, on my monitor, permits a window of
width of 225 characters.
By trimming down to 224 characters, I avoid
line wrap.
System crackers cannot cause a very long line
to wrap at just the right place to fake another
entry.
Sure, I'll perhaps miss important text beyond
the 225th char, but I'm willing to take
that risk.
Besides, the script converts tabs to a single
space and removes some common fields and
phrases which further cut down down on long
lines.
And I can always to back to the logs to look at
really long lines if I want to.
And yes, maybe some terminal emulator has
some long line bug somewhere.
My perl script helps avoid testing it.:-)
Some asked about my Perl filter for tailing
log files.
Sans typos, here is an example that removes
certain types of messages and fields,
checks the file every 60 seconds,
picks up trailing on the new file when
the log file gets rotated (moved away),
trims to
224 characters and replaces unusual chars
with ~'s (assuming you use ASCII).
/usr/bin/tail --retry --follow=name --max-unchanged-stats=60/var/www/logs/access_log |
/usr/bin/perl -ne '
$line = $_;
chomp $line;
next if $line =~ m{... some regexp you want to ignore...};
next if $line =~ m{... etc...};
$line =~ s/... some field you want to ignore...//;
$line =~ s/... some common phrase you want to ignore...//;
$line =~ s/^(.{1,224}).*$/$1/;
$line =~ s/\t //g;
$line =~ s/[^ -~]/~/g;
print "$line\n";'
As they say in perl, there is more than one
way to do it.
The above code fragment is just to give
you the general idea.
For those who might be concerned (and in case
the paper is/.-ed), the tested and found
that the following terminal emulators were
NOT susceptible to screen dump
or window title attacks:
I always pre-filter my logs thru a Perl script.
Besides removing verbose messages that are
not useful, my filters replace such
non-printable characters with a printable
character.
Not only does it make it easier to spot
strange octets on the screen, it does not
depend on the terminal emulator remaining
secure.
Slashdot Mirror
If ClearChannel is going to insist pushing these digital billboards with "time of day" related messages, then I hope they will turn down the brightness of their billboards at night as well.
You need a secondary DNS in case your site is cutoff from the net (backhoe cuts your cable), or if your ISP has routing/service problems, or if you suffer a loss of power for an extended period of time.
Loss of DNS service is more than people simply not being able to reach your site, loss of DNS service means EMail bounces (servers return EMail if they can no longer resolve your domain). Loss of DNS service means that web browsers tell your customers that you do not exist instead of simply telling them that you are down / not responding.
You want a secondary DNS that is located " elsewhere ". You want it far enough away that a single regional disaster (power outages, floods, earthquakes, etc.) does not take out both your primary DNS and your secondary DNS. You want your secondary DNS to have a distinct set of service providers to increase the chance that sites will be able to resolve your domain if the regional network is partitioned.
Run your own primary DNS. Make it a non-caching, non-forwarding, static, only answers queries for the domains it is authoritative. Then pick 1+ secondary DNS services that will slave off of your DNS master keeping in mind the points raised above.
One example of a secondary DNS Service is BackupDNS. They are inexpensive: Secondary DNS hosting your 150 domains would cost $28.50 US per month ($0.19 US per zone per month). They let you be in full control of your DNS service: Their site lets you new add zones, update (purge your zone on their servers and then force an reload) or remove zones on the fly. They will be a backup MX site if you like. They can even grok TSIG to improve the security of zone transfers. The BackupDNS folks are clueful, efficient, reliable and (unlike NetSol/Verisign) non-evil. I'm sure there are other secondary DNS Services that are both clueful, inexpensive. I mention these folks because we have had years of flawless secondary DNS service from them.
To sum it all up: Run a primary DNS to maximize the control and flexibility over your own domains. Use a clueful off-site secondary DNS service to maximize the chance that others will be able to resolve your domain.
- Websites Fighting the Nigerian Scam/419
- Nigerian Advance Fee Scam
- US Secret Service on 419
- Break The Chain
- 419 Coalition (as noted in the article)
Here are a few sites dedicated to exposing 419 scammers in an interesting and/or amusing way:If you don't care about last access times on your files, then you should consider mounting your filesystems with the noatime mount flag as in this /etc/fstab line:
Reading a file under noatime means that the kernel does not need to go back and update the last access time field of that file's inode. Sure, multiple reads over a span of a few seconds will only cause the in-core inode to be modified, but eventually that modified inode must be flushed out to disk. Why cause an extra write to the disk for a feature that you might not care about?
For example: think about those cron jobs / progs that scan the file tree (tmpwatch, updatedb, etc.). Unless you mount with the noatime option, your kernel must at least update the last access time fields of every directory's inode! Think about those /etc files that are
frequently read (hosts, hosts.allow, DIR_COLORS,
resolv.conf, etc.) or the dynamic shared libs
(libc.so.6, ld-linux.so.2, libdl.so.2, etc.)
that are frequently used by progs. Why
waste write-ops updating their last access
time fields?
Yes, the last access time field has some uses. However, the the cost of updating those last access timestamps, IMHO, is seldom worth the extra disk ops.
There are other advantages to using the noatime mount option ... however to
wind up this posting I'll just say that I
always mount my ext3 filesystems with the
noatime mount flag. I recommend that
you consider looking into this option if you
don't use it already.
You can find the name for "5 million trillion trillion" == 5e30 by using my English name of a number, an open source Perl program that can generate names of numbers of any size (e.g., the English name of the largest known prime).
In the above article, one could replace ''5 million trillion trillion pounds'' with:
And one could replace ''10 billion trillion trillion carats'' with:
Any retail or wholesale discount card that is not a line of credit, nor an instrument of debt (e.g, debit card) cannot require the consumer to disclose ANY information. They cannot even require you to provide your name! They cannot tie the use of a financial instrument (such as a credit, debit or check) back to the discount card account. Lastly, any consumer may lend or give their discount card to anyone else. You can use your discount card, hand it to the next person in line and apply for a new card the next time you come into the store if you wish.
At my California supermarket, at the bottom of the form there was a small box that says "I decline to provide any information". When I received my discount card application I quickly went to the very bottom, checked the box and immediately handed it back to the clerk. They clerk was clearly puzzled, but with a little prompting I managed to convince them I and completed the form and so I got my first card. Then to demonstrate the anonymity, I gave my card to the next person in line who didn't have a card. I'm currently using a card that I friend from out of town picked up (who also checked the box) and gave to me.
Some supermarkets have been slow to update their application forms, even thought the California law started 1-Jan-2001. I have had to help a friend deal with a supermarket who didn't want to give him a anonymous discount card. A call to the HQ of that supermarket cleared up the matter. (BTW: The store's excuse was that they had printed too many of the old forms that required comsumer information to toss them. Lame!) Perhaps the California law needs to be changed to prohibit the stores from even asking for such data?
So I won't be notified of a beef recall anytime soon. Not that I care. I'm a vegitarian. :-)
Stay tuned ...
The problem only shows up with only one filter at the lower end of the filter's spectral range. The amount of buildup and its effect on various frequencies has been measured. There is even a model for how the buildup has increased over time. A review of older data and instrument calibration may be able to further validate and refine this buildup model. In most cases old data that used this filter can be corrected to a reasonable degree. In nearly all cases, this buildup has a nil impact on the scientific conclusions that have thus far been produced.
NASA is examining a potential correction to the buildup. They are considering what is known as a "bakeout": going through a warm-up and cool-down cycle to boil off the contamination. They are going through a risk / reward analysis at the moment. The reward of a buildup reduction is being compared to the risk that the bakeout will move the contamination to other instruments. It is possible that the bakeout will happen in mid December, or it will be moved from mid-December to a later date or canceled altogether.
So while the buildup is not good / unfortunate, it appears to be neither fatal nor mission threatening at the moment.
P.S. To those who asked about the using the remaining on-board fuel to lower the bottom of the orbit to a shuttle serviceable level. The remaining on-board fuel is insufficient to do that ... a rough calculation shows that it
is 1-2 orders of magnitude too small.
Over the past 6 months, some 65% of spam (and spam attempts) that my ISP received came from less than 0.16% of the assigned IPv4 address space.
Almost 2/3's of the spam we saw was sent over SMTP connections from one of 77 CIDR blocks (ranging from /16 to /30 in size).
These 77 CIDR blocks represent less than 1/6 of
1 percent of the assigned IPv4 address space.
BTW: The CIDR list growth factor is not much when you move from the 65% level to the 90% level.
Spam is truly a world wide problem. Those 77 blocks, by national/region, break down as follows:
"Yes, Virginia", a few IP address blocks do transmit most of the spam.
My 37 Gemini page contains several images from the POSS2/UKSTU and the HST Phase 2 digital plate stacks.
you can file a complaint about Verisign to ICANN by using their:
n addition to a number of already posted suggestions, I recommend that you call Verisign and file a complain:
/dev/null. But I suspect that pressure from all fronts might help. I have been told (off the record) that some people within Verisign are not happy with their wildcarding. Complaints get logged into a database that these people can review. Your complaints, in volume, might help those folks make a stronger case against top-level wildcarding.
+1 703-742-0914 (worldwide)
+1 888-642-9675 (toll free US/Canada)
When you call, select:
* 1 (purchase an product or renew an exist product)
* then 7 (all other questions)
I recommend that you be patient with the Verisign rep that answers the phone. That person may not fully understand the issue / problem, and they are unlikely to personally be responsible for the Verisign decision. Remember that you are objecting what Verisign as a company is doing. Don't yell at the rep. Be polite but firm.
Ask Verisign to stop the wildcarding now. Explain why what they are doing is wrong (such as being unable to determine of a EMail message is being sent from a bogus / non-existent domain because thisdomaindoesnotexist.com resolves to 64.94.110.11).
If you do business with Verisign now, tell them that you will switch vendors unless Verisign stops this practice in X weeks. (fill in the X)
You might want to leave your phone number and request a callback. Anonymous complaints do not go as far.
If you are in the US, you might want to contact your local member of congress and object about what Verisign is doing. Let Verisign know that you are doing this when you call.
Yes, they might flush your complaint down
When you call, select:
I recommend that you be patient with the Verisign rep that answers the phone. That person may not fully understand the issue / problem, and they are unlikely to personally be responsible for the Verisign decision. Remember that you are objecting what Verisign as a company is doing. Don't yell at the rep. Be polite but firm.
Ask Verisign to stop the wildcarding now. Explain why what they are doing is wrong (such as being unable to determine of a EMail message is being sent from a bogus / non-existent domain because thisdomaindoesnotexist.com resolves to 64.94.110.11).
If you do business with Verisign now, tell them that you will switch vendors unless Verisign stops this practice in X weeks. (fill in the X)
You might want to leave your phone number and request a callback. Anonymous complaints do not go as far.
If you are in the US, you might want to contact your local member of congress and object about what Verisign is doing. Let Verisign know that you are doing this when you call.
Yes, they might flush your complaint down /dev/null.
But I suspect that pressure from all fronts might help.
I have been told
(off the record) that some people within
Verisign are not happy with their wildcarding.
Complaints get logged into a database that these
people can review.
Your complaints, in volume,
might help those folks make a
stronger case against top-level wildcarding.
Great mileage: You can drive it like a j-random normal 5-speed can and get about 63.5 MPG (3.7 L/100km). With a little practice and following some standard tips you can get a lot more. I usually get about 750 miles to 900 miles (about 1200 km to 1450 km) on a 11 US gal (41.6L) tank (68.1 MPG to 81.9 MPG == 3.45 L/100km to 2.87 L/100km).
Good pep: Pushed 108 MPH on a test track. Could have gone a bit higher but test track conditions were not the best. (Hint: your mileage suffers at that speed, so I don't recommend it that fast :-)).
More than enough zip to make it onto a
freeway with a short on-ramp.
Fun to drive. I love the idle stop feature (engine turns off under certain conditions). The digital display panel is well designed and can give you good feedback (out of the corner of you eye) what works
People really notice it, even after 2+ years. When gas prices in California push their way towards $2/Gal (and beyond :-( ), I
start to get a lot more people asking about it.
I highly recommend a visit to the www.insightcentral.net for detailed info on the Honda Insight, pictures of internal guts, tips and tricks owner forum, mileage database, etc.
Use of 10/8 can be a fine choice.
I know there are laws covering junk FAXes. I'm wondering if your FAX is on the Do-Not-Call List and you receive a junk FAX on it, then can you also go after the junk FAXer for violating the Do-Not-Call List?
Our LavaRnd project does not use Lava Lite(R) lamps.
Well, OK, we do have a Live LavaCan image that is sitting between two (but unrelated to the project) Lava Lite lamps. :-)
One of the SGI classic lavarand inventors (Bob Mende) is rebuilding the original classic site. Watch the LavaRnd news page for details.
So why do we call it LavaRnd? Well, one of the LavaRnd co-inventors likes to visit volcanoes, so we worked Lava into the name and site theme.
The LavaRnd source is about to be released. If you want to be notified about the release, join the LavaRnd-release mailing list.
Thanks to the support of John Gilmore and a very good lawyer, the case was resolved before we went to court. In the end, people were allowed to obtain source for the version of SMail that Amdahl shipped, and Amdahl agreed to follow the terms of the GPL (for SMail and any other GPL-ed code) from then on.
It is interesting to look at the 5 year view.
Both RHAT and SCOX fell during in the dot-com crash. SCOX fell a little deeper and then has recovered a bit making their 2 year numbers appear a bit better than normal. RHAT held its value somewhat during the that same period.
From the stock report SCOX fundamentals appear better than RHAT. On the other hand SCOX stock risk appears to be much higher than RHAT.
The Consensus Recommendation on SCOX over the last few years has been from weak hold to sell. Currently there is no consensus on SCOX. The Consensus Recommendation on RHAT over the last few years has been from weak hold to buy. Currently the consensus ranges between a hold and a strong buy for RHAT.
For the record: INACFP (I am not a certified Financial Planner). On the news of RHAT's lawsuit, I purchased some RHAT stock. You should carefully read the prospectus and research the stats of any company before trading it. If needed, seek professional advice before acting on any stock advice.
The Enigma is a bit cranky. The mechanical contact switches in the keyboard need to be cleaned more often and one might guess. The Enigma is not very ergonomic either ... :-)
We used that Enigma machine to encrypt a real message that was known to have been broken by the folks at Bletchley Park. Some 60 years ago, their code cracking machine took ~2h 45m to search about 1/2 the key space (during which several false positives turned up) before the real key was found. Turing's algorithm, ported to a stock Cray 1, took 30 seconds to find the same key.
The Cray 1, designed in the mid 70's, was only 330 times faster than the special purpose Bletchley Park code cracking complex. That 1940's technology used at Bletchley Park was truly amazing for its time.
p.s. Not only does the Computer History museum have a Cray 1, 2 and 3; it has one of every major model that Cray designed going way back to his early CDC days and his special Navy machine.
Lines such as:
serve as part of the ''removes certain types of messages'' processing. And lines such as:
serve as part of the ''removes certain types of ... fields'' processing.
And lines such as:
serve as part of the ''trims to 224 characters'' processing. And lines such as:
ensure that each message read is printed with a trailing newline.
To protect terminal emulators, the following lines are used:
For systems using ASCII (and a number of other widely used character sets), it replaces potentially dangerous characters with ~ (tilde) characters. The replacement is 1-for-1, so the layout of the original message is mostly preserved.
I say ''mostly preserved'' because a tabs are replaced with space. I prefer to view whitespace as just token separators and to reduce them where reasonable. A more complete whitespace crusher would use:
On the other hand, you might want to keep all whitespace as it is when tailing log messages in your terminal emulator window, so:
would do the trick.
And of course one could write the regexp to not depend on a character set order. I'll leave that exercise up to the reader. :-)
BTW: I prefer to replace strange characters instead of tossing them. Tossing strange characters instead of replacing them could would allow a system cracker to potentially mimic a valid messages knowing that invalid chars would simply be tossed. And I usually want to know when strange chars appear in the logs.
I hope this helps.
By trimming down to 224 characters, I avoid line wrap. System crackers cannot cause a very long line to wrap at just the right place to fake another entry.
Sure, I'll perhaps miss important text beyond the 225th char, but I'm willing to take that risk. Besides, the script converts tabs to a single space and removes some common fields and phrases which further cut down down on long lines. And I can always to back to the logs to look at really long lines if I want to.
And yes, maybe some terminal emulator has some long line bug somewhere. My perl script helps avoid testing it. :-)
The following terminal emulators were found, according to the article, to NOT be susceptible to screen dump or window title attacks:
Some asked about my Perl filter for tailing log files.
Sans typos, here is an example that removes certain types of messages and fields, checks the file every 60 seconds, picks up trailing on the new file when the log file gets rotated (moved away), trims to 224 characters and replaces unusual chars with ~'s (assuming you use ASCII).
As they say in perl, there is more than one way to do it. The above code fragment is just to give you the general idea.
I always pre-filter my logs thru a Perl script. Besides removing verbose messages that are not useful, my filters replace such non-printable characters with a printable character. Not only does it make it easier to spot strange octets on the screen, it does not depend on the terminal emulator remaining secure.