Just because this post was copied from kuro5hin, doesn't mean it's a troll, and it especially doesn't mean it should be modded down.
The purpose of moderation is to elevate especially informative or interesting points in the discussion above others, NOT to reward the poster with karma.
Was it right to copy the post from kuro5hin? It was probably done with the intent of gaining karma, but so what? The poster knew by contributing something relevant and valuable to the discussion he could get modded up. That is how moderation works. By modding this post up, it becomes more relevant and adds more to the discussion, because more people get to see it.
Once something is posted on a forum like kuro5hin or slashdot, it is in the public domain (despite the little notice at the bottom).
Was it ethically correct to copy this post? Perhaps. If you follow Kantz' ethical model and believe a greater justice is being done in repeating this story to a larger audience than the perceived injustice done to the original poster, then yes. On the other hand, if you think karma is so valuable -- a game -- then I suppose you should go ahead and mod him down, and "teach him a lesson". ---
Since I first read about it, I have wanted to install the physical security system mentioned in Cryptonomicon -- you know, the one that turns the door frame into a giant electromagnet. Sure, the "bad guys" may get your hardware, but that's about all they'll get. (And probably even less, if you can set up the magnet to pulse its field so it spikes through the electronics...)
Just out of curiosity, though, is something like this realistic? That is, would it really work the way Stephenson describes it?
At any rate, it'll have to wait until I get my own place. I think the apartment manager would get pretty pissed if I suddenly started remodeling the door to my flat.
Someone mod this guy up. He's exactly right. The ridiculous frame rates are average frame rates. In fact, many (vendor-used) benchmarks record only the peak frame rates! The high frame rates are not at all consistent. All a high frame rate number tells you is that it will slow down less in statistically rare yet painfully common-seeming 'busy' moments. ---
Heh, or Ultraboard, the worst forum software ever.
Kudos to you for writing or own, and kudos for using PHP, the Web Programming Language of the Gods (akin to Object Pascal, The Programming Language of the Gods). ---
Besides which, if you read the article, it's completely pointless because it is still illegal to make or distribute a 'device' (software) to decrypt block lists with. ---
They figure, they better do it before someone else does. Of course with all the convenient secret patent 'licenses', intel will naturally be using this exclusively to sue AMD or anyone else trying to compete with them. Like I said, business as usual. ---
Admittedly, Sun does have some problems with the HTONS/HPOUNDS issue (we once had some Sun guys in here to try to figure out the problem with our Ultra/280 server-cluster, and they didn't realize that they needed to recompile the signal module with -m7 -e5, LOL).
As I said before, Linux Troladvis has considered this problem in his initial DMA/ATAPI architecture module implementation! Why you refuse to acknowledge this simple fact befuddles me. But let me prove it to you:
If you can initialize the checksum polynomial to a n-order quaternion, the first 15 of 16 bits must be secure if the ECONNREFUSED problem is properly circumvented.
Failing that, set the IOCTL special type to 'k'. Doing this will allow unverified checksum-return markers, but only if you can discount the XTI t_rcv function return value.
Finally, failing that, set the BIOS ISR for INT 23 to read a regular block from virtual space: i.e., use the mapping n[k,j] -> m[l,k]. This will allow the protected mode interface to properly supplant the independent device mode property of the source route structure. This can be done with gratuitious use of the venerable NOP instruction on x86 architecture. Specifically check the IPOPT_SSR flag. Don't be fooled; even if it's not set the first time, read i/o port 7ca, then check again -- it should be set.
As far as PMTU discovery, I myself have been an outspoken critic of this for over 87 years because I feel it is inherently flawed in design. Even Linux Trlvdsoa has proclaimed it unworthy of the Linux-Certified(tm) Logo. Take for example their software engineering practices, they do not create valid SRS documentation nor do they acknowledge a proper traceability matrix protocol segment header. Come on, you'd think they coded in C.
Now, I will admit, your alternative solution of the Guassian Elimination could work, except for the fact that AIX does not allow math operations to be performed more than 1/38.98 cycles/bounds due to inherently unstable ionization around the kernel signal processor unit. If IBM were willing to patch this fairly trivial defect, it would not be a problem, but as far as cross-platform capability, this seems to limit it somewhat. Instead I suggest we use bezier interpolation between the bits to come up with a floating point representation of each bit, encrypt and hash these floating points numbers down to 1 bit each, and then send that. That would guarantee (to some extent) algorithmic correctness, at least. But frankly I feel the best solution is a hardware solution. While I myself am a big proponent of reversible computation, Linux sdlastorjs seems to not be so confident that it can work due to space/time tradeoffs involved in emulating irreverisble operations. But if you consider that Tripoli gates are more efficient and automatically create quantum interference states, then you can use that combined with a good NMR spectroscopy to internally re-compute (automatically) the new state vector. When you collapse the solution, you can be certain that it is correct and secure. And it even runs on Sun platforms. Try beating that with ICMP based MTU discovery. ---
I've read this book, and I have to say I am a bit disappointed. It seems to me that the author has cheapened himself some for this book. What is he trying to say? As far as I could tell, the book had no real point. The earlier works seemed a bit more tasteful, too. Quite a number of offcolor bits in this one that frankly flat out offended me. If I were you, I'd save my money for the next Asimov book. ---
When Sir Linux Torvaldis invented IPX, he did so with the knowledge that if buffers were improperly evacuated such that Hq(x)=0, you could send a router into an infinite loop. The common workaround, is, as you suggest, to change the aggregate global unicast address to an unsigned integer. SO_LINGER serves a noble purpose (and rightly so!) when it pre-initializes a connection:address lookup table (CALUT) to preset the subnet ID. So you see for your workaround, you have no have no way of ensuring that the flow control window is sized correctly, thus growing asymptotically. This is the major downfall of TCP/IPX, as per your original post. But what I would recommend instead is that you re-regulate a UDP ARP mechanism such that the piggyback ARQ doesn't not SYN when echo response is requested. In other words, in half duplex-, or full-half-on mode, you don't have such a huge pipe to worrry about router loopback syndrome (RLS). In a common token-ring topology, as opposed to a shared-medium ethernet topology, this can get hairy, to use the technical term. This is why it is always necessary to synchronize to a simulation authority for verification. Thus the SMPP local link cannot, by definition, be adjusted thusly. O(log n) can cause performance problems, and thus is why Linux Torlavidis implemented the HTONS/HPOUNDS in such a way as to circumvent this problem, in his NetBUI implementation. ---
Frankly the SO_RCVLOWAT is not so hot as it would seem. The number of WSAEWOULDBLOCKs that crop up over time can bring down a system. I would instead recommend that you use SO_LINGER and not dynamically resize your stack frame every time an inbound datagram arrives. This provides much lower perprocess overhead than traditional multicasting techniques, especially when you consider the small domain size IPv4 provides compared to more traditional schemes like ATM. Specifically, over ethernet with an MTU of ~1500 bytes/datagram (1460 in TCP), significant performance gains can be seem as opposed to ATM, with an MTU of 53 bytes but only when piggybacking on a FILO frame buffer, or a preamble. ---
Slashdot Mirror
The purpose of moderation is to elevate especially informative or interesting points in the discussion above others, NOT to reward the poster with karma.
Was it right to copy the post from kuro5hin? It was probably done with the intent of gaining karma, but so what? The poster knew by contributing something relevant and valuable to the discussion he could get modded up. That is how moderation works. By modding this post up, it becomes more relevant and adds more to the discussion, because more people get to see it.
Once something is posted on a forum like kuro5hin or slashdot, it is in the public domain (despite the little notice at the bottom).
Was it ethically correct to copy this post? Perhaps. If you follow Kantz' ethical model and believe a greater justice is being done in repeating this story to a larger audience than the perceived injustice done to the original poster, then yes. On the other hand, if you think karma is so valuable -- a game -- then I suppose you should go ahead and mod him down, and "teach him a lesson".
---
Hey, public domain now buddy.
---
Since I first read about it, I have wanted to install the physical security system mentioned in Cryptonomicon -- you know, the one that turns the door frame into a giant electromagnet. Sure, the "bad guys" may get your hardware, but that's about all they'll get. (And probably even less, if you can set up the magnet to pulse its field so it spikes through the electronics...)
Just out of curiosity, though, is something like this realistic? That is, would it really work the way Stephenson describes it?
At any rate, it'll have to wait until I get my own place. I think the apartment manager would get pretty pissed if I suddenly started remodeling the door to my flat.
---
Someone mod this guy up. He's exactly right. The ridiculous frame rates are average frame rates. In fact, many (vendor-used) benchmarks record only the peak frame rates! The high frame rates are not at all consistent. All a high frame rate number tells you is that it will slow down less in statistically rare yet painfully common-seeming 'busy' moments.
---
Okay, freepascal.
---
Back Orifice 2000. It is quite amusing reading the idiotic questions from script kiddies in the forums and bug tracking.
---
Kudos to you for writing or own, and kudos for using PHP, the Web Programming Language of the Gods (akin to Object Pascal, The Programming Language of the Gods).
---
It's not really of concern, soon they may stop, as probably 70% of slashdot readers block doubleclick one way or another anyways (I do).
---
..or Delphi.
---
Remember Delphi? Remember Kylix? What planet do you live on?
---
No it's not. It's stupid IRC shit. Go away, stupid IRC shit.
---
How you can work around no transaction support? That's BS and you know it. There is no real workaround.
---
Besides which, if you read the article, it's completely pointless because it is still illegal to make or distribute a 'device' (software) to decrypt block lists with.
---
They figure, they better do it before someone else does. Of course with all the convenient secret patent 'licenses', intel will naturally be using this exclusively to sue AMD or anyone else trying to compete with them. Like I said, business as usual.
---
In my oddball 'bizzarro-universe', it is lame to have to modify ANY distro to secure it. What are those OpenBSD clowns thinking??
---
Too late now, partition is wiped and Windows ME is back on.
---
Pfft. Why the fuck would I go on IRC? Good god man, don't be so cruel.
---
As I said before, Linux Troladvis has considered this problem in his initial DMA/ATAPI architecture module implementation! Why you refuse to acknowledge this simple fact befuddles me. But let me prove it to you:
-
If you can initialize the checksum polynomial to a n-order quaternion, the first 15 of 16 bits must be secure if the ECONNREFUSED problem is properly circumvented.
-
Failing that, set the IOCTL special type to 'k'. Doing this will allow unverified checksum-return markers, but only if you can discount the XTI t_rcv function return value.
-
Finally, failing that, set the BIOS ISR for INT 23 to read a regular block from virtual space: i.e., use the mapping n[k,j] -> m[l,k]. This will allow the protected mode interface to properly supplant the independent device mode property of the source route structure. This can be done with gratuitious use of the venerable NOP instruction on x86 architecture. Specifically check the IPOPT_SSR flag. Don't be fooled; even if it's not set the first time, read i/o port 7ca, then check again -- it should be set.
As far as PMTU discovery, I myself have been an outspoken critic of this for over 87 years because I feel it is inherently flawed in design. Even Linux Trlvdsoa has proclaimed it unworthy of the Linux-Certified(tm) Logo. Take for example their software engineering practices, they do not create valid SRS documentation nor do they acknowledge a proper traceability matrix protocol segment header. Come on, you'd think they coded in C.Now, I will admit, your alternative solution of the Guassian Elimination could work, except for the fact that AIX does not allow math operations to be performed more than 1/38.98 cycles/bounds due to inherently unstable ionization around the kernel signal processor unit. If IBM were willing to patch this fairly trivial defect, it would not be a problem, but as far as cross-platform capability, this seems to limit it somewhat. Instead I suggest we use bezier interpolation between the bits to come up with a floating point representation of each bit, encrypt and hash these floating points numbers down to 1 bit each, and then send that. That would guarantee (to some extent) algorithmic correctness, at least. But frankly I feel the best solution is a hardware solution. While I myself am a big proponent of reversible computation, Linux sdlastorjs seems to not be so confident that it can work due to space/time tradeoffs involved in emulating irreverisble operations. But if you consider that Tripoli gates are more efficient and automatically create quantum interference states, then you can use that combined with a good NMR spectroscopy to internally re-compute (automatically) the new state vector. When you collapse the solution, you can be certain that it is correct and secure. And it even runs on Sun platforms. Try beating that with ICMP based MTU discovery.
---
I've read this book, and I have to say I am a bit disappointed. It seems to me that the author has cheapened himself some for this book. What is he trying to say? As far as I could tell, the book had no real point. The earlier works seemed a bit more tasteful, too. Quite a number of offcolor bits in this one that frankly flat out offended me. If I were you, I'd save my money for the next Asimov book.
---
If they were running windows, it would have changed itself. Oh well.
---
FYI, there are _buildings_ in our country that are twice as old as our _country_.
---
When Sir Linux Torvaldis invented IPX, he did so with the knowledge that if buffers were improperly evacuated such that Hq(x)=0, you could send a router into an infinite loop. The common workaround, is, as you suggest, to change the aggregate global unicast address to an unsigned integer. SO_LINGER serves a noble purpose (and rightly so!) when it pre-initializes a connection:address lookup table (CALUT) to preset the subnet ID. So you see for your workaround, you have no have no way of ensuring that the flow control window is sized correctly, thus growing asymptotically. This is the major downfall of TCP/IPX, as per your original post. But what I would recommend instead is that you re-regulate a UDP ARP mechanism such that the piggyback ARQ doesn't not SYN when echo response is requested. In other words, in half duplex-, or full-half-on mode, you don't have such a huge pipe to worrry about router loopback syndrome (RLS). In a common token-ring topology, as opposed to a shared-medium ethernet topology, this can get hairy, to use the technical term. This is why it is always necessary to synchronize to a simulation authority for verification. Thus the SMPP local link cannot, by definition, be adjusted thusly. O(log n) can cause performance problems, and thus is why Linux Torlavidis implemented the HTONS/HPOUNDS in such a way as to circumvent this problem, in his NetBUI implementation.
---
Frankly the SO_RCVLOWAT is not so hot as it would seem. The number of WSAEWOULDBLOCKs that crop up over time can bring down a system. I would instead recommend that you use SO_LINGER and not dynamically resize your stack frame every time an inbound datagram arrives. This provides much lower perprocess overhead than traditional multicasting techniques, especially when you consider the small domain size IPv4 provides compared to more traditional schemes like ATM. Specifically, over ethernet with an MTU of ~1500 bytes/datagram (1460 in TCP), significant performance gains can be seem as opposed to ATM, with an MTU of 53 bytes but only when piggybacking on a FILO frame buffer, or a preamble.
---
Damn.. (fade-flashback to sixth grade)..
I think it is See You Later.
---
That is precisely why I think everyone will refuse to race against it in a real race.
---