They are only liable if you owe _more_. If they screw up and you pay more than you should have, you are SOL (been there, spent time with their "support" to explain exactly what their error was, they still didn't fix it).
Others have said that the area doesn't have cell service (at least not reliable coverage).
Call towers typically only cover a few miles (2-3 mile radius IIRC). Also, there has to be land-line phone service in the area already; that's how the towers are connected to the telephone network. A cell company is not going to pay the huge fees to run service to areas off the normal telco map; they'd never break even on the tower (and I don't think cell service is covered by the Universal Service Fund).
Guess what, the OpenSSH core developers won't discuss the issue in public either. The cipher in question was put in the OpenSSH source code with no discussion on the developers list and is the only cipher that is not mentioned anywhere in any OpenSSH documentation. There were several people asking why the cipher in question is in OpenSSH. The answer: silence.
The OpenSSH core developers don't want to discuss the issue with Red Hat; they want to dictate terms, make a political statement, and stir up trouble for those they disagree with.
No, those are built in to sendmail 8.13. They are very useful things; they keep a single or small number of systems (often zombies) from overloading our servers.
I've got some custom rulesets that apply extra strict limits to hosts listed in the MAPS DNSBLs; there is no point in allowing 10 or 100 connections from someone when we're just going to reject the mail anyway.
I work for an ISP, and we've been using Brightmail since before version 1. We use the MAPS DNS blocklists as a "front-line" defense and then Brightmail for spam and virus filtering. You can see our email statistics here.
I wrote the original sendmail milter interface to Brightmail that they derived their milter software from. We still run my milter because I've added additional options over time; Brightmail includes an SDK that you can use to interface to custom setups easily.
I work for an ISP, and we do not give anyone outside the system/network administration team root access to anything if at all possible. We have given network vendors (Redback and Ascend/Lucent) remote access to a device a couple of times (we changed the passwords on the particular device before and after), and we have one web application that we had to give the vendor root access for setup (but that was on a dedicated server).
Our antispam server is a dedicated server, but it still was screwed up once by the vendor. We were having a problem (only half our mail was actually being processed by the filters), and management directed that I go ahead and give the vendor support person access to the server (as the user the software runs under). He logged in to look at it, and within minutes the system was broke and mail was queueing up because the antispam software shut down and wouldn't restart. He had seen something unrelated to our problem that he thought didn't look right and decided to "fix" it for us. As soon as I got him to change it back, I told him to log out and removed his access (and they won't ever get it again).
After that, the only other time we considered allowing a vendor access was on a problem case that was over a year old that we had to have fixed ASAP. However, in that case, we were NOT going to allow remote access; the vendor was going to have to send somebody to us and we'd sit him down in front of the console (which would be logging) with us looking over his shoulder.
The only people that know your systems and network are your people (and you'll make enough mistakes). Vendors should not have access to change things at any point; at most they should get a "view" type account (they can look all they want but they can't touch). If something needs changing, they need to tell you and you can make the change (after evaluating it and having a back-out plan). For complex systems, you never end up installing software exactly the way the vendor specified; they are not going to know or understand changes you made for your local configuration (and how such changes affect other services and systems). Even a well-meaning "fix" can cause serious problems, and since it'll be your job to fix them, you better know what was done.
Burt Rutan's ship has never been to orbit and never will go to orbit (unless someone builds an orbital vehicle large enough to carry SpaceShip One as dead weight to an orbital museum).
The X Prize was about recreating the X-15 program, nothing more. Nobody with a clue would call 3 test flights (two of which experienced significant control problems) a step towards anything except more tests to better understand what happened. If they really cared about safety, they wouldn't have launched again after the 30 rolls without a lot more research and test flights, but they turned it around and launched it in 4 days anyway; it was all about the X Prize and the publicity.
After all, when NASA loses astronauts (and a vehicle), they have to shut down, get investigated by Congress, hear calls for them to be closed permanently, etc. If SpaceShip One had failed and killed the pilot, all we'd have heard about was what a hero he was for trying.
This is nothing close to the Mercury missions. Even the first two sub-orbital Mercury missions went nearly twice as high, and the rest were all orbital. This is closer to the X-15 project: carried up by a plane and dropped and then firing a rocket engine to just reach the edge of space. There is a big difference.
That has been solved for several years now (see for example DirecTV/Direcway). Satellite Internet access is used in many "out of the way" locations where running wire/fiber would make it cost prohibitive (IIRC a lot of Africa uses satellite for example).
The killer for satellite network access is latency. A typical DSL line has about a 20ms round trip (time for a packet to go from your network to the ISP network and back). If you lived on the equator directly under the satellite (and assuming the satellite adds no latency), you've just added 480ms to the round trip time. Move off the equator and to a different longitude, and latency gets even higher. This kills anything interactive (gaming, VOIP, telnet/SSH) and causes trouble for anything using TCP (window scaling wasn't expected to handle half second round trips).
What is done in some cases is to use special hardware on each end that adjusts TCP to better handle the latency. Also, I've heard some talk about putting caching servers on the satellites (so web access that hits the cache doesn't have to go up and down twice), but I don't know if anyone is doing that.
Speaking as someone that handles abuse@, I'll say that anything that standardizes complaint formats is a good thing (as long as everyone uses it of course). I have written several tools to automate abuse handling so that I can keep up with it (when "virus of the week" hits or a spammer signs up with a customer's customer; these aren't really preventable things), but that is time consuming. I'm trying to handle (in at least a semi-automatic way) AOL's feedback loop, SpamCop, DShield, SecurePipe, and myNetWatchman (which is way too many).
Another part of the problem with handling abuse is you can't really do much spam filtering on abuse@; if you do, you'll filter out legitimate spam complaints as well. However, since abuse@ is accepted most everywhere, it gets a ton of spam.
SYN cookies are for TCP connections (because TCP uses a three-way handshake to set up a connection). DNS uses (primarily) UDP traffic, which is connectionless (there is no "stateful" connection with UDP). SYN cookies do no good when your DNS servers are under attack.
I knew you couldn't scale explosives the same way, it was just a fun (if morbid) thought exercise. I didn't see the wingspan or the pics with something to give it a good scale. At 1/8, if you _could_ scale a bomb the same, you'd end up with 40 kiloton bomb.
The wingspan looks like about 6 feet to me, which would make it about 1/30 scale. IIRC, the bombs in Dr. Strangelove were supposed to be about 20 megatons. If you could scale the bomb the same way, you would still have a bomb with the force equivalent to about 740 tons of TNT. That's still a lot of deterrent to most things if delivered accurately; for example, the Oklahoma City bombing was equivalent to about 1.5 tons of TNT and the 9/11 World Trade Towers attack (both planes) equivalent to about 900 tons.
If they are going to attempt to patent fixes to security problems that they had early access to (i.e. they were notified about the problem prior to it being released to the public), that access should be stripped. The idea of early access is to cooperate and fix problems as fast as possible. Patenting a solution is not cooperation, so Cisco should lose their access.
BTW: one poster said "don't get excited, they'll do a reasonable and non-discriminitory license". That's nice, but it is useless for GPL software (unless they release an implementation under the GPL) and a trap for BSD licensed software (you can end up with code that says you can use it but you can't because of the patent).
Mail is important to people now, and you don't want to just lose a message. The way most mail servers work is that at the end of the SMTP DATA phase, before returning a successful response code, the server flushes the mail queue file(s) for that message to disk (i.e. they don't just close the files; they tell the OS to flush the blocks for those files to disk and don't return until they are written). That way, in case of crash, power failure, etc., the message is not lost. Then the server tells the other end "I've got it" by returning a success code.
If it were just in the kernel disk buffers or a RAMdisk, then a system crash or power failure would cause that message to be lost completely. Customers don't like lost mail (sure, crashes and power failures don't happen often, but do you want to explain that to the customer that didn't get the job offer, picture of his grandkids, etc.?).
I've got a mail server that uses an SSD for the mail queue filesystem.
It is great for that because the random I/O transactions per second
rating is 10,000 (vs. a typical hard drive thrashing hard at 150 tps).
The SSD we have is a Nitro!Xe from
Curtis, Inc.. It looks like a
standard 3.5" wide 1" high Ultra2 SCSI drive with an 80 pin SCA
connector. We have a 2G model with a 2.5" notebook drive for backup (it
has a battery to dump RAM to disk on power off) and it greatly improved
the performance of our mail server (high performance mail queue is all
about I/O TPS).
There is no easy way really. You have to just take the list of packages installed on your system (rpm -qa) and compare it to the list of packages in the development directory manually.
That isn't entirely true. In the development tree, packages will sometimes go backwards in version (i.e. from 1.1-1 to 1.0.5-2). When you just continue to do updates, you won't get such packages updated unless you manually track them down and use "rpm --oldpackage". This has happened with several packages lately IIRC.
Also, part of the point of the test release is to test the installer (and booting disc1:-) ). Since some of the defaults (i.e. SELinux) have changed in the installer, you don't have a "real" test3 system unless you install test3.
If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement...
Lots of GNU software (not just software under the GPL but software released by GNU) doesn't do that. For example: bash, gzip, ls,...
Your credit card statements wouldn't be enough. For example, IIRC shipping charges are exempt (at least in some places). Also, some on-line retailers already charge the appropriate sales tax (companies that already have a presence in your state are supposed to track and charge sales tax, and I know at least some do).
There is no reason to have a master password that gives someone with
that knowlege instant full access to every such device in the field.
There are many ways to work around it (without resorting to just
resetting the device and clearing all settings).
Cisco IOS routers don't have to have a "master password" backdoor; they
have a well-defined process for password recovery (typically you connect
to the console port, interrupt the boot at the firmware level, and
change a register - then you are in with no password and can reset it).
Another example: Livingston PortMasters also don't have a "master
password" backdoor. You hook up to the console port, flip a dip switch
and use a special login. That issues a challenge string, which you then
send to Livingston (or now portmasters.com). You get a respose string
and use it to log in, and then you change the password.
The common assumption is that full physical access implies ownership;
that is a reasonable assumption (since if someone can get at it, they
can take it).
Slashdot Mirror
They are only liable if you owe _more_. If they screw up and you pay more than you should have, you are SOL (been there, spent time with their "support" to explain exactly what their error was, they still didn't fix it).
Others have said that the area doesn't have cell service (at least not reliable coverage).
Call towers typically only cover a few miles (2-3 mile radius IIRC). Also, there has to be land-line phone service in the area already; that's how the towers are connected to the telephone network. A cell company is not going to pay the huge fees to run service to areas off the normal telco map; they'd never break even on the tower (and I don't think cell service is covered by the Universal Service Fund).
Guess what, the OpenSSH core developers won't discuss the issue in public either. The cipher in question was put in the OpenSSH source code with no discussion on the developers list and is the only cipher that is not mentioned anywhere in any OpenSSH documentation. There were several people asking why the cipher in question is in OpenSSH. The answer: silence.
The OpenSSH core developers don't want to discuss the issue with Red Hat; they want to dictate terms, make a political statement, and stir up trouble for those they disagree with.
No, those are built in to sendmail 8.13. They are very useful things; they keep a single or small number of systems (often zombies) from overloading our servers.
I've got some custom rulesets that apply extra strict limits to hosts listed in the MAPS DNSBLs; there is no point in allowing 10 or 100 connections from someone when we're just going to reject the mail anyway.
I wrote the original sendmail milter interface to Brightmail that they derived their milter software from. We still run my milter because I've added additional options over time; Brightmail includes an SDK that you can use to interface to custom setups easily.
I work for an ISP, and we do not give anyone outside the system/network administration team root access to anything if at all possible. We have given network vendors (Redback and Ascend/Lucent) remote access to a device a couple of times (we changed the passwords on the particular device before and after), and we have one web application that we had to give the vendor root access for setup (but that was on a dedicated server).
Our antispam server is a dedicated server, but it still was screwed up once by the vendor. We were having a problem (only half our mail was actually being processed by the filters), and management directed that I go ahead and give the vendor support person access to the server (as the user the software runs under). He logged in to look at it, and within minutes the system was broke and mail was queueing up because the antispam software shut down and wouldn't restart. He had seen something unrelated to our problem that he thought didn't look right and decided to "fix" it for us. As soon as I got him to change it back, I told him to log out and removed his access (and they won't ever get it again).
After that, the only other time we considered allowing a vendor access was on a problem case that was over a year old that we had to have fixed ASAP. However, in that case, we were NOT going to allow remote access; the vendor was going to have to send somebody to us and we'd sit him down in front of the console (which would be logging) with us looking over his shoulder.
The only people that know your systems and network are your people (and you'll make enough mistakes). Vendors should not have access to change things at any point; at most they should get a "view" type account (they can look all they want but they can't touch). If something needs changing, they need to tell you and you can make the change (after evaluating it and having a back-out plan). For complex systems, you never end up installing software exactly the way the vendor specified; they are not going to know or understand changes you made for your local configuration (and how such changes affect other services and systems). Even a well-meaning "fix" can cause serious problems, and since it'll be your job to fix them, you better know what was done.
Burt Rutan's ship has never been to orbit and never will go to orbit
(unless someone builds an orbital vehicle large enough to carry
SpaceShip One as dead weight to an orbital museum).
The X Prize was about recreating the X-15 program, nothing more. Nobody
with a clue would call 3 test flights (two of which experienced
significant control problems) a step towards anything except more tests
to better understand what happened. If they really cared about safety,
they wouldn't have launched again after the 30 rolls without a lot more
research and test flights, but they turned it around and launched it in
4 days anyway; it was all about the X Prize and the publicity.
After all, when NASA loses astronauts (and a vehicle), they have to shut
down, get investigated by Congress, hear calls for them to be closed
permanently, etc. If SpaceShip One had failed and killed the pilot, all
we'd have heard about was what a hero he was for trying.
This is nothing close to the Mercury missions. Even the first two
sub-orbital Mercury missions went nearly twice as high, and the rest
were all orbital. This is closer to the X-15 project: carried up by a
plane and dropped and then firing a rocket engine to just reach the edge
of space. There is a big difference.
Unless you had an add-on (or the hack from Antic IIRC that used a 4 column wide font), the Atari 800 only had 40 column output.
I found every single one of them. They're all right here on my globe.
The killer for satellite network access is latency. A typical DSL line has about a 20ms round trip (time for a packet to go from your network to the ISP network and back). If you lived on the equator directly under the satellite (and assuming the satellite adds no latency), you've just added 480ms to the round trip time. Move off the equator and to a different longitude, and latency gets even higher. This kills anything interactive (gaming, VOIP, telnet/SSH) and causes trouble for anything using TCP (window scaling wasn't expected to handle half second round trips).
What is done in some cases is to use special hardware on each end that adjusts TCP to better handle the latency. Also, I've heard some talk about putting caching servers on the satellites (so web access that hits the cache doesn't have to go up and down twice), but I don't know if anyone is doing that.
Speaking as someone that handles abuse@, I'll say
that anything that standardizes complaint formats is a good thing (as
long as everyone uses it of course). I have written several tools to
automate abuse handling so that I can keep up with it (when "virus of
the week" hits or a spammer signs up with a customer's customer; these
aren't really preventable things), but that is time consuming. I'm
trying to handle (in at least a semi-automatic way) AOL's feedback loop,
SpamCop, DShield, SecurePipe, and myNetWatchman (which is way too many).
Another part of the problem with handling abuse is you can't really do
much spam filtering on abuse@; if you do, you'll filter out
legitimate spam complaints as well. However, since abuse@ is
accepted most everywhere, it gets a ton of spam.
SYN cookies are for TCP connections (because TCP uses a three-way
handshake to set up a connection). DNS uses (primarily) UDP traffic,
which is connectionless (there is no "stateful" connection with UDP).
SYN cookies do no good when your DNS servers are under attack.
I knew you couldn't scale explosives the same way, it was just a fun (if morbid) thought exercise. I didn't see the wingspan or the pics with something to give it a good scale. At 1/8, if you _could_ scale a bomb the same, you'd end up with 40 kiloton bomb.
The wingspan looks like about 6 feet to me, which would make it about 1/30 scale. IIRC, the bombs in Dr. Strangelove were supposed to be about 20 megatons. If you could scale the bomb the same way, you would still have a bomb with the force equivalent to about 740 tons of TNT. That's still a lot of deterrent to most things if delivered accurately; for example, the Oklahoma City bombing was equivalent to about 1.5 tons of TNT and the 9/11 World Trade Towers attack (both planes) equivalent to about 900 tons.
If they could get Ricard Montalban as well, it might be interesting.
BTW: one poster said "don't get excited, they'll do a reasonable and non-discriminitory license". That's nice, but it is useless for GPL software (unless they release an implementation under the GPL) and a trap for BSD licensed software (you can end up with code that says you can use it but you can't because of the patent).
If it were just in the kernel disk buffers or a RAMdisk, then a system crash or power failure would cause that message to be lost completely. Customers don't like lost mail (sure, crashes and power failures don't happen often, but do you want to explain that to the customer that didn't get the job offer, picture of his grandkids, etc.?).
The SSD we have is a Nitro!Xe from Curtis, Inc.. It looks like a standard 3.5" wide 1" high Ultra2 SCSI drive with an 80 pin SCA connector. We have a 2G model with a 2.5" notebook drive for backup (it has a battery to dump RAM to disk on power off) and it greatly improved the performance of our mail server (high performance mail queue is all about I/O TPS).
There is no easy way really. You have to just take the list of packages
installed on your system (rpm -qa) and compare it to the list of
packages in the development directory manually.
Also, part of the point of the test release is to test the installer (and booting disc1 :-) ). Since some of the defaults (i.e. SELinux) have changed in the installer, you don't have a "real" test3 system unless you install test3.
You mean like Ford is having with the Mustang?
Your credit card statements wouldn't be enough. For example, IIRC
shipping charges are exempt (at least in some places). Also, some
on-line retailers already charge the appropriate sales tax (companies
that already have a presence in your state are supposed to track and
charge sales tax, and I know at least some do).
Cisco IOS routers don't have to have a "master password" backdoor; they have a well-defined process for password recovery (typically you connect to the console port, interrupt the boot at the firmware level, and change a register - then you are in with no password and can reset it).
Another example: Livingston PortMasters also don't have a "master password" backdoor. You hook up to the console port, flip a dip switch and use a special login. That issues a challenge string, which you then send to Livingston (or now portmasters.com). You get a respose string and use it to log in, and then you change the password.
The common assumption is that full physical access implies ownership; that is a reasonable assumption (since if someone can get at it, they can take it).