Ok, thanks for the additional info. It sounds like a store-and-forward version of RPC. I can see how that would be useful, and would prefer to be more lightweight.
BTW, human interaction isn't required for SMTP/POP/whatever traffic. You could put your reliability at at the application layer with perhaps some headers for ACK/NACK, etc.
That is really what this comes down to.. if you're going to try to make something asynchronous reliable, you're going to need an ACK/NACK/missing ACK solution.. basicly all the same pitfalls of TCP over unreliable IP. You might as well just spawn a thread to deliver the message to a host:port TCP address tuple and skip all the queuing.
The only reason then to have the queuing would probably be regulatory.. which makes sense for the financial sector.
There is no guarantee that the receiver will ever pick up the message from the queue. Just like SMTP, I can send you a message, but there is no guarantee that you will ever look at your mailspool/inbox/pop server/imap server. My point is that it is no better than SMTP.
And how can any of those things going wrong be prevented with another protocol and not SMTP?
1. server screws up the queue - possible on anything with badly coded software 2. messages delivered twice - each message has a unique message-id, allowing the detection of duplicates. 3. message stuck in a loop - possible with any routable store-and-forward system 4. same message repeated multiple times - see #2 5. spool being filled - possible with any store-and-forward system
Sounds like the same issues rehashed, SMTP or message queuing.
Asynchronous connection precludes reliability. If there is no receiver waiting, there is no gurantee that the message will get to the recipient. At best, the sender will get a bounce message.
Surprise, surprise, this sounds just like SMTP.
Perhaps some poor misguided soul came up with this protocol because their experience was with Exchange. I can't think of another reason to reinvent the wheel like this.
What systems detect fork bombs? Last time I tried it, it was very easy to bring a linux or FreeBSD system to its knees. It wasn't even a memory consumption issue, it simply starved other processes of CPU time and lengthened the time needed for the scheduler to decide on which process to run. It can be hard to recover from, and it grows geometricly.
In case you don't know what we're talking about here, this is how simple fork bombs can be:
BTW, for windows, there is a great tool called MacShift that will allow you to randomize your MAC address. Just make a shortcut and run it before you connect to any wireless network, and you'll have a different one each time. No tracing there.
2) [...] Kernel does not support loadable kernel modules (which makes it a pain to change a network card, as the kernel must be recompiled).
FYI, this provides only limited protection. Yes, someone won't be able to insmod a rootkit, but with access to/dev/kmem, they can overwrite kernel memory as needed. See Phrack issue 58, article 0x07.
They can make things look more proportional, but the LCD hardware is not capable of displaying all of the colors of the CRT hardware. This is mostly due to the flourescent backlight. See http://en.wikipedia.org/wiki/Color_gamut
I just got a 20" 1600x1200 LCD after years of using a 19" CRT in the same resolution.
What this article does not talk about is color gamut. CRTs are able to display a much wider range of color compared to LCDs. Any application where color is important (desktop publishing, graphics work, etc.) will want to use a CRT for the forseeable future. On this LCD, whites are not really white, blacks are not really black.
That said, the LCD display really does very well in two areas: 1) lack of refresh rate, even at 60Hz things are nice and solid. 2) lack of convergence artifacts. Because each pixel has seperate addressable color components, you don't have to worry about gun convergence like CRTs. Individual pixels are nice and sharp. On lower priced CRTs (particularly OEM ones) convergence is often never quite right. If the convergnce is adjusted properly for one area of the screen, it will be off in another. Buying a higher priced CRT will end up with better results, but be sure it is always transported in its original packaging, or else the convergence can get shot to hell.
Both CRTs and LCDs have their probelms and benefits, and the choice between them depends on what your application is. For my purposes, I think I will end up going with a CRT and LCD dual-display system. I'll see how that goes.
After reading the full letter to American Airlines, this issue takes on new meaning. This information was attempted to be gathered in the UK, and thus would be subject to UK privacy laws. Also, this was supposedly to fufill a mystery TSA regulation that is not consistently applied. This issue is not at all about customs, this came up upon checking in, while still in the UK. I'm now curious to see AA's response.
When you fill out customs forms entering foreign countries, you are usually required to state where you will be staying. Hotel, residence, whatever. I had to do it going to Japan, and my wife's cousin had to do it when entering the US coming from Japan.
Actually the story is pretty funny, she didn't have my in-laws' address with her, and she had to get the help of the customs agents to make some phone calls to find it.
What is the big deal anyway? As a foreign national on a tourist/temporary visit visa, I don't find it unusual or unnecessary to ask for this info.
NYSERnet (New York State Educaction and Research network) was the only provider for my school in Rochester, NY. Our packets ended up routed through some awful Sprintlink drop in Washington DC before they went anywhere. That sprintlink drop had all kinds of problems, high latency, bad routing to pretty much everywhere, and would occasionally just stop forwarding packets.
NYSERnet may be fine for those organizations in NYC, but for upstate, it really sucked.
They went through some upgrades in the past couple years, so hopefully things have gotten better. But NYSERnet really is a sore subject for me. It ruined many a Quake game.:(
I also have an Indy that I picked up for free. Mine had its hard disk wiped, so I never had a copy of IRIX for it. But I was able to boot a linux-mips kernel and bootstrap a debian installation. It worked quite well.
Netboot is a bit of a pain to figure out. Be sure to read the faq. Now I've upgraded to debian woody, and things are working well. X works with a 256-color display, making it fine for an X terminal. I wouldn't try to run Mozilla or something on it with its 32Mb of ram, but its quite functional, with all of Debian available.
That is interesting.. because I have noticed that some spammers use the backup MX records as their primary target. This seems to be because most backup MX records will accept any mail destined to the domain, regardless of if it is to a valid mailbox or not. Then the backup MX has to deal with generating a bouce to the non-existant From: address.
Dropping keys from the keyring presents problems with the trust path. For example, A signs B's key. B signs C's key. A now has a trust path to C. If B is dropped from the keyring, no new users can authenticate that trust path. With the current scheme, if N signs A's key, N would now have a trust path to C. With the new scheme, the link to B and C is broken because he can't retrieve B's key.
Having an email address expire is not a reason to no longer trust a key.
This kind of stupid nationalism effects Free Software too.
Herbert Xu, a Debian Developer and maintainer of the Debian Linux Kernel package, resigned from Debian in May 2004 due to a dispute over the use of a Taiwanese flag.
because of their massive weight, per passenger they use more fuel than an SUV
Are you only considering the diesel-electric train lines? You should consider electrified train lines; not having to carry a big generator and fuel supply around with them makes them much much more efficient.
One of the results of fusion is free neutrons, going off into whatever material surrounds the fusion process. In the case of the tokamak, neutrons can't be confined by magnetic fields because they are electrically neutral. The neutrons make the tokamak itself become highly radioactive over time, and will cause it to eventually be decommissioned because it is too dangerous to work around.
Now, granted, the tokamak can be stored unused for a hundred years or so and then recommissioned (it is a hell of a lot better than the thousand-years half-lives of fission wasteproducts), but it is still a problem that needs to be addressed.
Um, how does the state know the ethnicity of these people? How were the relations decided? From birth certificates?? Man, I really underestimated the amount of data collation that the state does.:(
Slashdot Mirror
Ok, thanks for the additional info. It sounds like a store-and-forward version of RPC. I can see how that would be useful, and would prefer to be more lightweight.
BTW, human interaction isn't required for SMTP/POP/whatever traffic. You could put your reliability at at the application layer with perhaps some headers for ACK/NACK, etc.
That is really what this comes down to.. if you're going to try to make something asynchronous reliable, you're going to need an ACK/NACK/missing ACK solution.. basicly all the same pitfalls of TCP over unreliable IP. You might as well just spawn a thread to deliver the message to a host:port TCP address tuple and skip all the queuing.
The only reason then to have the queuing would probably be regulatory.. which makes sense for the financial sector.
I'll stop rambling now.
-molo
There is no guarantee that the receiver will ever pick up the message from the queue. Just like SMTP, I can send you a message, but there is no guarantee that you will ever look at your mailspool/inbox/pop server/imap server. My point is that it is no better than SMTP.
-molo
And how can any of those things going wrong be prevented with another protocol and not SMTP?
1. server screws up the queue - possible on anything with badly coded software
2. messages delivered twice - each message has a unique message-id, allowing the detection of duplicates.
3. message stuck in a loop - possible with any routable store-and-forward system
4. same message repeated multiple times - see #2
5. spool being filled - possible with any store-and-forward system
Sounds like the same issues rehashed, SMTP or message queuing.
-molo
Asynchronous connection precludes reliability. If there is no receiver waiting, there is no gurantee that the message will get to the recipient. At best, the sender will get a bounce message.
Surprise, surprise, this sounds just like SMTP.
Perhaps some poor misguided soul came up with this protocol because their experience was with Exchange. I can't think of another reason to reinvent the wheel like this.
-molo
I do not disagree about setrlimit() being a suitable solution. The original claim however was:
Now there's protections in most kernels just to detect a fork bomb and stop it.
I wanted to know what kernels did that.. and how.
-molo
Using setrlimit() is not detecting fork bombs.
-molo
In case you don't know what we're talking about here, this is how simple fork bombs can be:
BTW, for windows, there is a great tool called MacShift that will allow you to randomize your MAC address. Just make a shortcut and run it before you connect to any wireless network, and you'll have a different one each time. No tracing there.
-molo
2) [...] Kernel does not support loadable kernel modules (which makes it a pain to change a network card, as the kernel must be recompiled).
/dev/kmem, they can overwrite kernel memory as needed. See Phrack issue 58, article 0x07.
FYI, this provides only limited protection. Yes, someone won't be able to insmod a rootkit, but with access to
-molo
They can make things look more proportional, but the LCD hardware is not capable of displaying all of the colors of the CRT hardware. This is mostly due to the flourescent backlight. See http://en.wikipedia.org/wiki/Color_gamut
-molo
I just got a 20" 1600x1200 LCD after years of using a 19" CRT in the same resolution.
What this article does not talk about is color gamut. CRTs are able to display a much wider range of color compared to LCDs. Any application where color is important (desktop publishing, graphics work, etc.) will want to use a CRT for the forseeable future. On this LCD, whites are not really white, blacks are not really black.
That said, the LCD display really does very well in two areas: 1) lack of refresh rate, even at 60Hz things are nice and solid. 2) lack of convergence artifacts. Because each pixel has seperate addressable color components, you don't have to worry about gun convergence like CRTs. Individual pixels are nice and sharp. On lower priced CRTs (particularly OEM ones) convergence is often never quite right. If the convergnce is adjusted properly for one area of the screen, it will be off in another. Buying a higher priced CRT will end up with better results, but be sure it is always transported in its original packaging, or else the convergence can get shot to hell.
Both CRTs and LCDs have their probelms and benefits, and the choice between them depends on what your application is. For my purposes, I think I will end up going with a CRT and LCD dual-display system. I'll see how that goes.
-molo
Sorry to respond to my own message, but..
After reading the full letter to American Airlines, this issue takes on new meaning. This information was attempted to be gathered in the UK, and thus would be subject to UK privacy laws. Also, this was supposedly to fufill a mystery TSA regulation that is not consistently applied. This issue is not at all about customs, this came up upon checking in, while still in the UK. I'm now curious to see AA's response.
-molo
When you fill out customs forms entering foreign countries, you are usually required to state where you will be staying. Hotel, residence, whatever. I had to do it going to Japan, and my wife's cousin had to do it when entering the US coming from Japan.
Actually the story is pretty funny, she didn't have my in-laws' address with her, and she had to get the help of the customs agents to make some phone calls to find it.
What is the big deal anyway? As a foreign national on a tourist/temporary visit visa, I don't find it unusual or unnecessary to ask for this info.
-molo
NYSERnet (New York State Educaction and Research network) was the only provider for my school in Rochester, NY. Our packets ended up routed through some awful Sprintlink drop in Washington DC before they went anywhere. That sprintlink drop had all kinds of problems, high latency, bad routing to pretty much everywhere, and would occasionally just stop forwarding packets.
:(
NYSERnet may be fine for those organizations in NYC, but for upstate, it really sucked.
They went through some upgrades in the past couple years, so hopefully things have gotten better. But NYSERnet really is a sore subject for me. It ruined many a Quake game.
-molo
I also have an Indy that I picked up for free. Mine had its hard disk wiped, so I never had a copy of IRIX for it. But I was able to boot a linux-mips kernel and bootstrap a debian installation. It worked quite well.
Netboot is a bit of a pain to figure out. Be sure to read the faq. Now I've upgraded to debian woody, and things are working well. X works with a 256-color display, making it fine for an X terminal. I wouldn't try to run Mozilla or something on it with its 32Mb of ram, but its quite functional, with all of Debian available.
-molo
That is interesting.. because I have noticed that some spammers use the backup MX records as their primary target. This seems to be because most backup MX records will accept any mail destined to the domain, regardless of if it is to a valid mailbox or not. Then the backup MX has to deal with generating a bouce to the non-existant From: address.
-molo
This would require shutting down or disabling backup MX servers also. Or, maybe changing the DNS records to remove backup MX servers.
Regardless, it would be pretty desperate to do that.
BTW, it took 48 hours to upgrade a MTA?! I'm glad I don't use Exchange.
-molo
Dropping keys from the keyring presents problems with the trust path. For example, A signs B's key. B signs C's key. A now has a trust path to C. If B is dropped from the keyring, no new users can authenticate that trust path. With the current scheme, if N signs A's key, N would now have a trust path to C. With the new scheme, the link to B and C is broken because he can't retrieve B's key.
Having an email address expire is not a reason to no longer trust a key.
-molo
This kind of stupid nationalism effects Free Software too.
Herbert Xu, a Debian Developer and maintainer of the Debian Linux Kernel package, resigned from Debian in May 2004 due to a dispute over the use of a Taiwanese flag.
Resignation on debian-boot with references to context
start of thread on debian-devel
-molo
because of their massive weight, per passenger they use more fuel than an SUV
Are you only considering the diesel-electric train lines? You should consider electrified train lines; not having to carry a big generator and fuel supply around with them makes them much much more efficient.
-molo
One of the results of fusion is free neutrons, going off into whatever material surrounds the fusion process. In the case of the tokamak, neutrons can't be confined by magnetic fields because they are electrically neutral. The neutrons make the tokamak itself become highly radioactive over time, and will cause it to eventually be decommissioned because it is too dangerous to work around.
Now, granted, the tokamak can be stored unused for a hundred years or so and then recommissioned (it is a hell of a lot better than the thousand-years half-lives of fission wasteproducts), but it is still a problem that needs to be addressed.
-molo
Where is the BSA when you need them? :)
-molo
They wanted my film. I used up the last shot on the roll just by taking a picture of the floor, and then I handed the film over.
The point is that my civil right were violated.
Not if you voluntarily gave over the film. If they asked for it and you refused and they took it anyway, then you would have a case.
-molo
CNN Transcript here
-molo
Um, how does the state know the ethnicity of these people? How were the relations decided? From birth certificates?? Man, I really underestimated the amount of data collation that the state does. :(
-molo