And how is this a win over just sending the same packets multiple times?
Sending the same packet multiple time leads to a higher volume (you at least double the volume), for actually less fault tolerance.
Suppose you have a file made up of a hundredblocks, and that we have a 5% probability of packet loss.
In case you transmit each packet twice, you have for each packet a 0.05 * 0.05 probability = 0.25%
that you loose both. This may seem small, but if
you calculate it, you'll see that the probability of that not happening for any of the 100 packets is quite small: (1-0.0025)^100 = 77.8%. So, you have roughly one chance in 4 of not transmitting your file in its entirety. And to achieve this modest result, you needed to transmit 200 packets, rather than 100.
Now compare this to FEC: you transmit a number of additional packets which can be used to compensate for any loss, not just for its companion packet. Just adding 20 more packets brings the total probability of a successful complete transmission to 99.9999% (that's the probability that less than 20 packets are lost out of 120, given an individual loss probability of 5%). So you transmit less packets (120 rather than 200), and you get a higher assurance of overall transmission success.
If you expect to lose 4 packets out of 5, you need to turn 20MB into a lot more than 100MB.
You are right, you need slightly more to cover "standard deviation". If you toss a coin 100 times, it's very rare that you get exactly 50 heads. You may get 40, you may get 60. That's due to standard deviation, but the effect wears off the bigger your sample. So more than 100MB will be necessary, but not substantially more.
If you transmit 100 packets, and expect to receive 20 of them, the chances that you transmitted the right 20 is very very slim. And you absolutely cannot produce a scheme where any 20 will give you the right answer.
Please reread my post. Any 20 are ok, that's the whole point.
This information must be transferred reliably and in order
Order is easy to take care off. Just add a sequence number to your packets to tell them apart (yes, that's another overhead, but it's small).
You simply cannot have two different sets of 20MB be equivalent, because if you do, you lose information (pidgeon-hole principle). So given 19 packets that are received, there is exactly one 1 MB packet which can be received.
Well, if you re-read my posting, you'll see that yes, any 20 packets would be enough to reconstruct the information (as long as they are different, of course...duplicating a same packet 20 times won't work obviously).
It's been a while since I've calculated hamming distances, so I'm not going to get into the exact number of packets that need to be sent, but I hope that my discussion above showed that the number is greater than simply multiplying by the inverse of the expected reliability.
The number is indeed greater (due to standard deviation), but not substantially so.
You might also want to check out udpcast which provides a working implementation of a FEC algorithm, that works in practice (albeit only on "slice" sizes of up to 128 packets, but that's purely for practical reasons: in theory no such limitation would be necessary).
As some people have mentioned, you can use UDP with FEC to achieve some error correction. But meta-content can handle long burst errors, whereas FEC is only appropriate for short, random errors.
This depends on the parameters of your FEC algorithm. Most FEC algorithm do indeed divide the data to be transmitted into "slices" of n blocks, to which they add k blocks. If more than k blocks are lost per slice, you're SOL, even if enough extra blocks are available in other slices. However, there is a way around that: just tune your FEC algorithm so as to make n large enough that all of your file fits into one slice.
The downside of this is that the larger the slice is, the more computationnally intensive it is. If the only thing you're concerned about are burst errors, just interleave your slices.
You can literally unplug the ethernet, wait a while, and plug it back in, and you're still good to go with Digital Fountain, as long as you listen long enough.
This is possible with run-of-the-mill FEC algorithms as well, as long as you put your entire file into a single giant slice.
Absolutely. The only usefulness for this would be in a situation where two-way communication is simply not possible. There are improvements which can be made to TCP for file transfers, but dropping all feedback mechanisms is simply stupid.
Dropping all feedback is interesting in situations where:
there is a very high latency, and feedback would arrive so late that it would seriously slow things down (i.e. satellite links)
the return channel is costly (again, satellite links, with a terrestial (dial-in) return channel). If you can do away with the return channel, you win the cost of dialing in, which is interesting if you are on a metered telco, as is common in Europe.
As far as only a certain number of packets being required to be received on the other end, that is either completely false, or the overhead is astronomical. More likely it is just plain wrong, or this product is complete vaporware to begin with.
This is feasible in a way to make the number of extra packets tuneable to the expected loss.
The algorithm is indeed based XOR, but that's not the only component though. The idea is to define a field on the set of all byte (or short, or word...) values. You use XOR as the addition, and Galois multiplication as the multiplication.
Then you treat your data blocks as vectors, of which you can do linear combinations in the Galois field.
If you have n data blocks to transmit, and want to add k redundant blocks, you first arrange your n data blocks in an n-element vector. Then you multiply that vector with an n times n+k Vandermonde matrix to optain a new vector of n+k elements. Those n+k elements are the blocks which will be effectively transmitted
A Vandermonde matrix is a matrix having the following form:
1 x_1^1 x_1^2 x_1^3...
1 x_2^1 x_2^2 x_2^3...
1 x_3^1 x_3^2 x_3^3...
1 x_4^1 x_4^2 x_4^3... .......
A square Vandermonde matrix has the interesting property of being inversible. Moreover, a subset of rows of a Vandermonde matrix is still a Vandermonde matrix. Loosing packets is equivalent to dropping rows (as each one of the n+k transmitted packets is obtained by multiplying one row of the matrix by the vector of the original n packets).
The receiver just calculates the remaining Vandermonde matrix (by striking out the rows that correspond to the dropped packets, plus some more if less than k were dropped), and inverts the remaining matrix. By multiplying this inverse with the vector of received blocks, the receiver can obtain the original vector of n data packets.
The nice thing about this is that k is freely tuneable (as long as the field is big enough: but if you define your field over 4 byte values, that should not be a problem). So, you just take a value for k that matches the expected loss rate plus some comfortable safety margin, and you're set. Considering that, turning 20MB into 100MB will only be necessary if you expect to loose 4 packets out of 5...
Of course, all this doesn't resolve the issue of flow control, so the sender needs to be tuned manually such as not to emit faster than the physical link can handle.
Udpcast in FEC mode does this too: in addition to the original data, it can transmit an arbitratry amount of "FEC" blocks which are a linear combination of the data blocks. If some data blocks are lost in transit, udpcast can recalculate them from the FEC blocks by multiplying the vector of received data by the inverse encoding matrix.
Please check out www.broadwing.net.
I've heard they've got great broadband offerings, and have a backbone based on all fiber. Even if you don't buy service from them, please take at least the time to phone them and ask them about their service. Thanks;-)
Note to the audience: Broadwing is a nasty spam haven, and the world will be a much better place once they'll be out of business.
So, what's the best way to upgrade?
on
Linux 2.4.16 Released
·
· Score: 4, Interesting
Ok, say you are running 2.4.15 now. You are compiling 2.4.16. And now you want to reboot with the new kernel. But reboot implies unmount, which might trigger the bug! So what would be the safest way to jump off that 2.4.15 timebomb? Is this a situation where just pushing the reset button would be safer than a clean shutdown?
Would remounting the filesystems read-only help? Or would that also trigger the bug?
And, if your filesystems are reiserfs, do you need to worry too, or does this only affect the traditional filesystems.
Whenever I read someone saying that they are forced to use windows at work I cringe.
Does this company have a policy against using anything other than windows?
At my former job (a bank), company policy was indeed that windows was mandatory. So those jobs do exists. Funny that anybody would doubt this, I always lived under the impression that most jobs required windows, and that places where you are allowed to run Linux on the desktop (such as my current job) were still the exception.
If they do, I doubt that the poster will be permitted to run KDE even if it is win32.
Good point. Indeed, during the first couple of month, while working on a java project, it was impossible to get permission to install Cygwin. However, after that I got involved in a project with Tcl, and as there is (fortunately) no Visual Tcl, I got permission to install Cygwin, Emacs, the works. Certainly, being good friends with the guy in charge of security helped too, but this experience shows that places which mandate Windows, while still allowing Cygwin do indeed exist.
The fact of the matter is that this guy uses windows at work to be productive as his line of work is in win32 applications no doubt.
Nope. In general such policies exist to make IT support more productive. If they only have to know one operating system, it's easyer for them. Although this may seem backwards (IT are there to support the users, not the other way round), this is unfortunately what happens in many places.
so that all the applications don't perform the same searches of (possibly very long and crowded on the system of someone who likes eye-candy) icon directories
... which would be a non-issue anyways if you use reiserfs...
Analog modem emulation over ISDN. Indeed, the complicated part of the driver is emulating the DSP with its signal processing algorithms, whereas actually interfacing to the device is the easy part.
Such an analog-over-isdn driver could be
interesting in the following situations:
You occasionnally connect to serveral providers, some analog, some isdn, and you don't want to keep around both an ISDN card and an analog modem.
You run a small co-op ISP, and want to offer 56K access. As you probably know, end-user 56K modems only work for the client side, not for the ISP side. ISPs need different equipment, which is much more expensive, and only makes sense for large commercial ISPs. However, with ISDN, it could easily be emulated, if there was such as softmodem driver around
Actually, the possibility of running analog modem protocol over ISDN would be an excellent testing platform for softmodem developpers: indeed, anybody good enough to write a softmodem driver would probably be to smart to have a real winmodem lying around. Which means he would have to buy one specifically for the purpose of writing this driver. With ISDN, he can use equipment which he probably already has.
In France, there is a rule that a modem should not be allowed to redial a same number too many times after failures, until it is reset.
This is intended to prevent that unattended systems, where the phone number of the peer is misset for some reason, accidentally harress an innocent third party all through the night by calling every five minutes...
A low level driver could easily bypass such rule, which would theoretically make it necessary to certify it.
Every competent network administrator distrusts the inside as much as the outside.
This is even more true if the institution to be "protected" is a school. It's as necessary to protect the world outside from your own evil students than it is to protect your network from the world outside...
Exactly, I'm curruntly working in a bank where I only have access to the outside using the port 80, that doesn't avoid the fact I can receive any kind of files using my webmail server !
Exactly. And if the bank you work at allows https traffic, it's even more fun: as https is normally encrypted, the firewall cannot even make sure that the traffic passing over port 443 is indeed https. When I worked at a bank, I had telnet servers running on port 443 of a couple of machines outside, and could happily log in to them from work...
A) No one is forcing you to upgrade. If you are throwing the bleeding edge onto Prod servers you deserve what you get. That doesn't just apply to Linux, it applies to Solaris, AIX, HP-UX, Windoze and everything else. Get a clue.
True, as long as the kernel is labeled "bleeding edge". As far as I understood, that was what the even/odd numbering was for: 2.3.x, 2.5.x unstable, but 2.2.x and 2.4.x stable. "Even" kernels are meant to only receive bugfixes or rather peripheral additions (new drivers, yes, and also new filesystems), but no fundamental changes (new VM...).
If this had happened during 2.3.x, nobody would have complained. People even don't expect the 2.3.x kernels to compile... After all, this is what the development branch is for. But on the other hand, such changes have no place in the so-called stable branch.
Your complaint can be applied to the case of adding driver support to an existing kernel. You see, in the life of a kernel, time passes. As time passes, new hardware, software, algorithms, etc. come out. In order for us to keep modern, we have to add new things to the existing set. You're just... silly.
Isn't that what development kernel (2.3.x, 2.5.x) should be for?
How do you convert an ext2 partition to reiserfs anyways? The best method I could come up was using a spare partition somewhere else: copy data over to spare partition, mkreiserfs the original, and then copy it back. Obviously, this doesn't work if you don't have any spare disk space lying around. So, is there somewhere a utility to do the conversion "in place"? How safe is it (i.e. what happens if there is a power failure right in the middle of it?)
Just wear a pizza delivery shirt and carry a big red bag.. Never fails, everyone trusts the pizza guy..
Nope, this trick won't work everywhere. At a bank where I used to work, standard procedures for such a case would be that the pizza guy left the pizza at the security guy, who then called the guy who ordered it to come down and pick it up.
Same drill if you had a visitor. You'd have to come down physically to meet him.
And all this was even before September 11th, but the place was so paranoid that they chose to build their underground parking lot below the garden rather than below the building, for fear of February 26th, 1993 type events...;-)
Re:Tucows and GPL?
on
LWN in Trouble
·
· Score: 4, Interesting
I submitted a GPL Windows app I wrote (Nographer) in the hope they would include it on their site, and it was rejected without explanation.
Same thing happened to me with a Linux app. I replied, asking for a reason (just in case it was something silly, which would be easily correctible). No answer.
However, the funny thing is that they still kept sending me spam, about how I could upgrade the placement of my app by sending them $500... and boasting about their some zillions of hits per month. Then another mail apologizing the first was wrong, that it was actually zillions of hits per week. I replied to the spam saying there was still the issue with my app. No answer (predictably).
Then somebody contacted me with a question about another application that I already had on tucows... and I brought up the subject of the new app up again. Eventually, after a couple of e-mail exchanges the guy suggested me to resubmit it, and lo and behold, it got accepted this time. Persistence pays;-)
This will have repercussions on long-distance communications & electrical transmission.
No problem. People will just blame it on the IIS worm du jour, predict Internet Death at 11 (tm), and later sheepishly admit that this time it was actually solar flares that ate the bandwidth...
, an EMC chamber is basically a room which has been heavily shielded to prevent any outside electromagnetic signals from getting inside.
Here is an experiment that everybody can do at home, without having an EMC chamber, and the output is quite...errmh... different:
Put cell phone in microwave oven
Close door
No, DON'T SWITCH THE MICROWAVE ON. Reserve that experiment for your Windows XP CD's...
Call the phone from another phone: it still rings...
If your phone has a reception quality indicator, observe it: reception is almost as good as outside.
So you may wonder: why is this behavior supposed to be strange? Well, microwave ovens are supposed to be shielded to prevent the microwaves getting out and cooking the innards of however happens to be standing in the kitchen... However, from what I've heard, mobile phone use waves which are quite close in frequency to microwaves. So how is it possible that the phone can still communicate, even inside the shielding? Any RF engineer care to comment?
> just like you don't see them hauling up Ameritech on charges every time a bomb threat is phoned in somewhere
But Ameritech will gladly supply the footage from the hidden surveillance camera in the phone booth that was used to phone in the threat, making it trivial to find the culprit;-)
Oops, wrong telco, wrong country. But think about it next time you feel tempted to use a "fortress phone..."
I run a DeCSS website, and do indeed block a largish list of known MPAA affiliated IP's. Moreover anything that has law in its hostname gets blocked too, unless it is from Poland (where law is often part of town names, etc => too many false positives).
People from blocked IPs just see This site has been shut down for legal reasons.
People who are not blocked see the page, but at the bottom it has the following disclaimer:
The presence of protective measures on this site does not constitute an admission of guilt, but are rather due to the realization that fighting through a suit can become a timeconsuming and expensive undertaking, even if winning eventually. Btw, come to think of it, these protective measure could even fall under the DMCA, so beware if you're a lawyer, and are seeing this site...
So far, in the almost two years that the site has been up, I've only gotten a single shark-o-gram, and even that one didn't insist after I just ignored him...
Before that, I used similar techniques for a site critical of E*Trade, in order to keep E*Trade's lawyers out...
> I haven't heard from a single client who has actually had downtime from it.
At work, we had a Lotus Domino server that would crash whenever someone requested an non-existant Web URL from it (don't ask...). As most access to it are done from programs, or from links & bookmarks, this hasn't actually been a problem until recently...
Since the beginning of August it started crashing every hour or so, making it rather difficult to work with. Then, this week it crashed every ten minutes... Initially we assumed that unknowingly a coworker was mistyping an URL, or doing some bizarre tests which crashed it. Then we understood what was really happening: it was CODE RED! Does that qualify as client having downtime due to Code Red?
However, in retrospect, this whole story had a good thing to it: it encouraged the guy in charge of Notes to find out why exactly it was crashing when asked for a non-existing URL... And he did indeed find the faulty config option and fixed it.
Ok, now on the next task: another of our Domino servers crashes whenever somebody enters a bad password into the HTTP password dialog box for protected pages (yeah, yeah, I know...). Now that the weekend is approaching, and the kiddies are putting their final touches onto their new creations, could somebody please include an Authorization: Basic Tm90ZXM6c3V4b3Jz0 into the HTTP headers of the probes of his Code Red III, so that we have an excuse to fix that problem too?;-)
> Unfortunately, I believe this is tied to the way that Lotus Notes is implemented. If you hadn't noticed, notes.net is actually a Notes DB being served up on the web via a Domino server. Notes uses Javascript for all web-based events when doing this.
AFAIK, even in Lotus Notes itself Javascript is optional (it is more useful for filling out Lotus documents over the Web, but less for static contents). And actually most of the hyperlinks on notes.net are ok, except the download links. Which proves that it's somehow possible to have plain hyperlinks, even in Domino.
Btw, Lotus is not the only site to gratuitously require javascript. There is also http://www.polytechniciens.com/, who for some reason thought it was smart to wrap all their contents of their main page into document.write() statements. Oddly enough, the
page still can be viewed (without the Javascript) at http://www.polytechniciens.com/index.html.
And most boorish of all http://www.cordis.lu
who just do it with a <NOSCRIPT> tag. This is a government sponsored site, which normally should know better than to wilfully restrict people's access in such a way. Blind people browsing with lynx and a braille line are effectively shut out of the site. While the government spends millions to retrofit their physical buildings with ramps to present easy access for the disabled, cordis's id10t webmaster thinks he's so leet shutting them out in this want-on manner...
Slashdot Mirror
... the first caricatures of Bill Gates with beard and turban start to appear.
Sending the same packet multiple time leads to a higher volume (you at least double the volume), for actually less fault tolerance.
Suppose you have a file made up of a hundredblocks, and that we have a 5% probability of packet loss.
In case you transmit each packet twice, you have for each packet a 0.05 * 0.05 probability = 0.25% that you loose both. This may seem small, but if you calculate it, you'll see that the probability of that not happening for any of the 100 packets is quite small: (1-0.0025)^100 = 77.8%. So, you have roughly one chance in 4 of not transmitting your file in its entirety. And to achieve this modest result, you needed to transmit 200 packets, rather than 100.
Now compare this to FEC: you transmit a number of additional packets which can be used to compensate for any loss, not just for its companion packet. Just adding 20 more packets brings the total probability of a successful complete transmission to 99.9999% (that's the probability that less than 20 packets are lost out of 120, given an individual loss probability of 5%). So you transmit less packets (120 rather than 200), and you get a higher assurance of overall transmission success.
You are right, you need slightly more to cover "standard deviation". If you toss a coin 100 times, it's very rare that you get exactly 50 heads. You may get 40, you may get 60. That's due to standard deviation, but the effect wears off the bigger your sample. So more than 100MB will be necessary, but not substantially more.
If you transmit 100 packets, and expect to receive 20 of them, the chances that you transmitted the right 20 is very very slim. And you absolutely cannot produce a scheme where any 20 will give you the right answer.
Please reread my post. Any 20 are ok, that's the whole point.
This information must be transferred reliably and in order
Order is easy to take care off. Just add a sequence number to your packets to tell them apart (yes, that's another overhead, but it's small).
You simply cannot have two different sets of 20MB be equivalent, because if you do, you lose information (pidgeon-hole principle). So given 19 packets that are received, there is exactly one 1 MB packet which can be received.
Well, if you re-read my posting, you'll see that yes, any 20 packets would be enough to reconstruct the information (as long as they are different, of course...duplicating a same packet 20 times won't work obviously).
It's been a while since I've calculated hamming distances, so I'm not going to get into the exact number of packets that need to be sent, but I hope that my discussion above showed that the number is greater than simply multiplying by the inverse of the expected reliability.
The number is indeed greater (due to standard deviation), but not substantially so.
If you're interested in the specifics, please read Luigi Rizzo's paper.
You might also want to check out udpcast which provides a working implementation of a FEC algorithm, that works in practice (albeit only on "slice" sizes of up to 128 packets, but that's purely for practical reasons: in theory no such limitation would be necessary).
This depends on the parameters of your FEC algorithm. Most FEC algorithm do indeed divide the data to be transmitted into "slices" of n blocks, to which they add k blocks. If more than k blocks are lost per slice, you're SOL, even if enough extra blocks are available in other slices. However, there is a way around that: just tune your FEC algorithm so as to make n large enough that all of your file fits into one slice.
The downside of this is that the larger the slice is, the more computationnally intensive it is. If the only thing you're concerned about are burst errors, just interleave your slices.
You can literally unplug the ethernet, wait a while, and plug it back in, and you're still good to go with Digital Fountain, as long as you listen long enough.
This is possible with run-of-the-mill FEC algorithms as well, as long as you put your entire file into a single giant slice.
Dropping all feedback is interesting in situations where:
- there is a very high latency, and feedback would arrive so late that it would seriously slow things down (i.e. satellite links)
- the return channel is costly (again, satellite links, with a terrestial (dial-in) return channel). If you can do away with the return channel, you win the cost of dialing in, which is interesting if you are on a metered telco, as is common in Europe.
As far as only a certain number of packets being required to be received on the other end, that is either completely false, or the overhead is astronomical. More likely it is just plain wrong, or this product is complete vaporware to begin with.This is feasible in a way to make the number of extra packets tuneable to the expected loss.
The algorithm is indeed based XOR, but that's not the only component though. The idea is to define a field on the set of all byte (or short, or word...) values. You use XOR as the addition, and Galois multiplication as the multiplication.
Then you treat your data blocks as vectors, of which you can do linear combinations in the Galois field.
If you have n data blocks to transmit, and want to add k redundant blocks, you first arrange your n data blocks in an n-element vector. Then you multiply that vector with an n times n+k Vandermonde matrix to optain a new vector of n+k elements. Those n+k elements are the blocks which will be effectively transmitted
A Vandermonde matrix is a matrix having the following form:
1 x_1^1 x_1^2 x_1^3 ... ... ... ...
.......
1 x_2^1 x_2^2 x_2^3
1 x_3^1 x_3^2 x_3^3
1 x_4^1 x_4^2 x_4^3
A square Vandermonde matrix has the interesting property of being inversible. Moreover, a subset of rows of a Vandermonde matrix is still a Vandermonde matrix. Loosing packets is equivalent to dropping rows (as each one of the n+k transmitted packets is obtained by multiplying one row of the matrix by the vector of the original n packets).
The receiver just calculates the remaining Vandermonde matrix (by striking out the rows that correspond to the dropped packets, plus some more if less than k were dropped), and inverts the remaining matrix. By multiplying this inverse with the vector of received blocks, the receiver can obtain the original vector of n data packets.
The nice thing about this is that k is freely tuneable (as long as the field is big enough: but if you define your field over 4 byte values, that should not be a problem). So, you just take a value for k that matches the expected loss rate plus some comfortable safety margin, and you're set. Considering that, turning 20MB into 100MB will only be necessary if you expect to loose 4 packets out of 5...
Of course, all this doesn't resolve the issue of flow control, so the sender needs to be tuned manually such as not to emit faster than the physical link can handle.
Udpcast in FEC mode does this too: in addition to the original data, it can transmit an arbitratry amount of "FEC" blocks which are a linear combination of the data blocks. If some data blocks are lost in transit, udpcast can recalculate them from the FEC blocks by multiplying the vector of received data by the inverse encoding matrix.
Note to the audience: Broadwing is a nasty spam haven, and the world will be a much better place once they'll be out of business.
Would remounting the filesystems read-only help? Or would that also trigger the bug?
And, if your filesystems are reiserfs, do you need to worry too, or does this only affect the traditional filesystems.
Does this company have a policy against using anything other than windows?
At my former job (a bank), company policy was indeed that windows was mandatory. So those jobs do exists. Funny that anybody would doubt this, I always lived under the impression that most jobs required windows, and that places where you are allowed to run Linux on the desktop (such as my current job) were still the exception.
If they do, I doubt that the poster will be permitted to run KDE even if it is win32.
Good point. Indeed, during the first couple of month, while working on a java project, it was impossible to get permission to install Cygwin. However, after that I got involved in a project with Tcl, and as there is (fortunately) no Visual Tcl, I got permission to install Cygwin, Emacs, the works. Certainly, being good friends with the guy in charge of security helped too, but this experience shows that places which mandate Windows, while still allowing Cygwin do indeed exist.
The fact of the matter is that this guy uses windows at work to be productive as his line of work is in win32 applications no doubt.
Nope. In general such policies exist to make IT support more productive. If they only have to know one operating system, it's easyer for them. Although this may seem backwards (IT are there to support the users, not the other way round), this is unfortunately what happens in many places.
This is intended to prevent that unattended systems, where the phone number of the peer is misset for some reason, accidentally harress an innocent third party all through the night by calling every five minutes...
A low level driver could easily bypass such rule, which would theoretically make it necessary to certify it.
This is even more true if the institution to be "protected" is a school. It's as necessary to protect the world outside from your own evil students than it is to protect your network from the world outside...
Exactly. And if the bank you work at allows https traffic, it's even more fun: as https is normally encrypted, the firewall cannot even make sure that the traffic passing over port 443 is indeed https. When I worked at a bank, I had telnet servers running on port 443 of a couple of machines outside, and could happily log in to them from work...
True, as long as the kernel is labeled "bleeding edge". As far as I understood, that was what the even/odd numbering was for: 2.3.x, 2.5.x unstable, but 2.2.x and 2.4.x stable. "Even" kernels are meant to only receive bugfixes or rather peripheral additions (new drivers, yes, and also new filesystems), but no fundamental changes (new VM...).
If this had happened during 2.3.x, nobody would have complained. People even don't expect the 2.3.x kernels to compile... After all, this is what the development branch is for. But on the other hand, such changes have no place in the so-called stable branch.
Isn't that what development kernel (2.3.x, 2.5.x) should be for?
How do you convert an ext2 partition to reiserfs anyways? The best method I could come up was using a spare partition somewhere else: copy data over to spare partition, mkreiserfs the original, and then copy it back. Obviously, this doesn't work if you don't have any spare disk space lying around. So, is there somewhere a utility to do the conversion "in place"? How safe is it (i.e. what happens if there is a power failure right in the middle of it?)
Nope, this trick won't work everywhere. At a bank where I used to work, standard procedures for such a case would be that the pizza guy left the pizza at the security guy, who then called the guy who ordered it to come down and pick it up.
Same drill if you had a visitor. You'd have to come down physically to meet him.
And all this was even before September 11th, but the place was so paranoid that they chose to build their underground parking lot below the garden rather than below the building, for fear of February 26th, 1993 type events... ;-)
Same thing happened to me with a Linux app. I replied, asking for a reason (just in case it was something silly, which would be easily correctible). No answer.
However, the funny thing is that they still kept sending me spam, about how I could upgrade the placement of my app by sending them $500... and boasting about their some zillions of hits per month. Then another mail apologizing the first was wrong, that it was actually zillions of hits per week. I replied to the spam saying there was still the issue with my app. No answer (predictably).
Then somebody contacted me with a question about another application that I already had on tucows... and I brought up the subject of the new app up again. Eventually, after a couple of e-mail exchanges the guy suggested me to resubmit it, and lo and behold, it got accepted this time. Persistence pays ;-)
No problem. People will just blame it on the IIS worm du jour, predict Internet Death at 11 (tm), and later sheepishly admit that this time it was actually solar flares that ate the bandwidth...
Here is an experiment that everybody can do at home, without having an EMC chamber, and the output is quite ...errmh... different:
- Put cell phone in microwave oven
- Close door
- No, DON'T SWITCH THE MICROWAVE ON. Reserve that experiment for your Windows XP CD's...
- Call the phone from another phone: it still rings...
- If your phone has a reception quality indicator, observe it: reception is almost as good as outside.
So you may wonder: why is this behavior supposed to be strange? Well, microwave ovens are supposed to be shielded to prevent the microwaves getting out and cooking the innards of however happens to be standing in the kitchen... However, from what I've heard, mobile phone use waves which are quite close in frequency to microwaves. So how is it possible that the phone can still communicate, even inside the shielding? Any RF engineer care to comment?But Ameritech will gladly supply the footage from the hidden surveillance camera in the phone booth that was used to phone in the threat, making it trivial to find the culprit ;-)
Oops, wrong telco, wrong country. But think about it next time you feel tempted to use a "fortress phone..."
People from blocked IPs just see This site has been shut down for legal reasons.
People who are not blocked see the page, but at the bottom it has the following disclaimer:
So far, in the almost two years that the site has been up, I've only gotten a single shark-o-gram, and even that one didn't insist after I just ignored him...Before that, I used similar techniques for a site critical of E*Trade, in order to keep E*Trade's lawyers out...
At work, we had a Lotus Domino server that would crash whenever someone requested an non-existant Web URL from it (don't ask...). As most access to it are done from programs, or from links & bookmarks, this hasn't actually been a problem until recently...
Since the beginning of August it started crashing every hour or so, making it rather difficult to work with. Then, this week it crashed every ten minutes... Initially we assumed that unknowingly a coworker was mistyping an URL, or doing some bizarre tests which crashed it. Then we understood what was really happening: it was CODE RED! Does that qualify as client having downtime due to Code Red?
However, in retrospect, this whole story had a good thing to it: it encouraged the guy in charge of Notes to find out why exactly it was crashing when asked for a non-existing URL... And he did indeed find the faulty config option and fixed it.
Ok, now on the next task: another of our Domino servers crashes whenever somebody enters a bad password into the HTTP password dialog box for protected pages (yeah, yeah, I know...). Now that the weekend is approaching, and the kiddies are putting their final touches onto their new creations, could somebody please include an Authorization: Basic Tm90ZXM6c3V4b3Jz0 into the HTTP headers of the probes of his Code Red III, so that we have an excuse to fix that problem too? ;-)
AFAIK, even in Lotus Notes itself Javascript is optional (it is more useful for filling out Lotus documents over the Web, but less for static contents). And actually most of the hyperlinks on notes.net are ok, except the download links. Which proves that it's somehow possible to have plain hyperlinks, even in Domino.
Btw, Lotus is not the only site to gratuitously require javascript. There is also http://www.polytechniciens.com/, who for some reason thought it was smart to wrap all their contents of their main page into document.write() statements. Oddly enough, the page still can be viewed (without the Javascript) at http://www.polytechniciens.com/index.html.
And most boorish of all http://www.cordis.lu who just do it with a <NOSCRIPT> tag. This is a government sponsored site, which normally should know better than to wilfully restrict people's access in such a way. Blind people browsing with lynx and a braille line are effectively shut out of the site. While the government spends millions to retrofit their physical buildings with ramps to present easy access for the disabled, cordis's id10t webmaster thinks he's so leet shutting them out in this want-on manner...