And plenty of people who are using it quite happily. See EarthLink's SpamBlocker for a related approach that uses a kind of challenge to help the user populate his whitelist / address book.
There's always plenty of documentation on why something is a really bad idea. "'Considered Harmful' Considered Harmful". I clean out my spam folder once a week or more, and haven't found fewer than 1000 messages in it, usually 2000, for as long as I can remember. These are desperate times.
The CLR is a stack-based virtual machine..NET languages are first compiled into (MS)IL, which is the code for that Virtual Machine. Upon execution the JIT compiler translates the IL operations of the virtual machine into native code for the actual target machine.
What exactly do you think VM means? Are you perhaps reacting to the nasty connotations from.NET's poorly marketed predecessor systems?
It's great that MS has technology which can make all code "blazing". That'll save me a lot of time optimizing some of the cretinous code I have to deal with.
Also, the memory footprint (RSS) for gtk-hello-world.exe is 7.3Mbytes, which is a lot for something that only puts up an empty window. JITs have their costs, and native batch compilers really do have their place.
There are lost of ahead-of-time compilers for modern languages which produce programs with large memory footprints. Among them: GCJ. So if the GNU compiler can't work miracles with Java, there's no reason to assume it'll work miracles with C# (+ the runtime and huge class library) either.
There are effective approaches to reducing footprint that have nothing to do with when the bytecode is turned into native code. Tree-shaking is one that worked for Lisp and similar systems. (That does require static ahead-of-time program *analysis*, but that's different.) Sharing VMs for different programs is another.
The downside is that you may lose some of the dynamic capabilities of the language.
A transaction can provide the ACID properties throughout the duration of the transaction. Most importantly for read-only operations, you have Isolation. Isolation let you perform your queries without being affected by ongoing writes.
This is better than a lock, which another poster suggested, as a lock will block all writers, while a transaction need not block anybody.
Millions of phones can access the web: most of them can do WAP/WML or its forebears, some of them WMLScript, some of them HTML 4 or some subset, but only tiny minority that can run any Javascript. Vastly more phones can run Java (J2ME) MIDlets than can execute Javascript. And, no, most websites don't perform terribly well on a phone.
Furthermore, there's nothing in the HTML standards that requires Javascript. I'm not sure where you got that idea.
It's great that your phone can do Javascript. You can't really reason about the rest of reality from that fluke.
Some other guy has written some other tiny little app with limited appeal. How is this news? He uses XHTML?
Say, I have a program that calculates the specific density and body fat percentage of my cats...and you can access it via the WORLD WIDE WEB! Oh, yeah, and everything is first output into XML 1.1, then transformed by an XSLT stylesheet into XSL:FO, which is then rendered into PDF with embedded Javascript, which I then transform into WBMP for output to my cell phone through WAP Push. Every five minutes I also receive updates via animated MMS messages, and my car's 802.11 telematic system has a holographic heads-up display of the instantaneous fat accumulation rate of each feline, broken down topologically. When it drops below a threshold determined by an expert system, which is accessed via the venerable ELIZA protocol, a fiber optic quantum-encrypted transmitter activates a remote twinkie feeder device to compensate. Um...I think the twinkies might contain carbon nanotubes or buckyball-nougat or something.
I'm porting the whole system to be C# running on Mono-current running on Parrot running on FreeBSD running on VMWare running on Linux running on my home-built liquid-cooled micro form factor Opteron multimedia PC.
There's a difference between (allegedly) idly speculating about something and actually doing something about proving or disproving it...or in this case, exploring the idea in excruciating detail.
> TCP is a layer above IP which is (drum roll please).... ALL IN SOFTWARE
I suggest you look at any number of modern router implementations, and more to the point, TCP and IPSEC "offload" network cards from 3com, Adaptec, Alacritech, and others. For that matter, decent ethernet NICs have been doing checksumming in the hardware for aeons now.
(Of course, this has nothing to do with Fast TCP.)
As somebody who works for a company who was minding its own business when the boys in Blue showed up waving patent claims at us, I have to say that IBM doesn't just defend itself with its alleged IP. It's out there beating the bushes for victims.
Right, a dictionary attack would never, ever guess jester2. I mean, it's a dictionary word PLUS A SINGLE DIGIT NUMBER! If you could see the mail logs on any major ISP's servers during a spam dictionary attack, you'd know that spammers will blindly try a great number of combinations.
Furthermore, I had a similar problem with an e-mail address that I know wasn't sold because I was the one hosting it. It turns out that somehow I had taken some spyware onboard, and it was sending all my form submissions to some unscrupulous collector.
(Yes, I use Linux, too; no, it can't replace Windows for everything I need to do.)
Blocking mail from small sites using dynamic DNS is also a useful tool. No single tool in the effort to stop spam is sufficient, nor are most of them painless.
The industry is considering several anti-spam measures that would form a "web of trust" between SMTP senders. The burden of joining that web of trust will likely be too high for Joe Linux User, just as hosting a permanent SSL/TLS-protected site with a *valid* site certificate is generally too much trouble for a home access user.
If you want your mail to be accepted, smarthost it to your upstream provider or to any major mail provider that provides SMTP relay services. Their relays had better be authenticated, of course, because ISPs will continue to crack down on mail through open relays.
Used for ROM? What do you think they're storing in there?
The 4 gibibyte per-process RAM limit is a limitation of some operating systems, and it's not always 2GiB. A 32-bit processor can address 4GiB just fine. As has been mentioned, with segmentation or bank-swapping techniques like PAE. It's distasteful, but it can be useful in some applications.
There's nothing terribly wrong with RC4. I hate to see its good name sullied like this. It's cheap, well-understood, and widely implemented. If you're accessing a web page with SSL/TLS, you're probably using the RC4 cipher.
As you say, the major problem with WEP's use of RC4 was in the selection of weak IV's. The other major issue was in key management. If long-lived, shared, static keys are replaced with short-lived, individual keys for unicast traffic, the security of WEP is greatly enhanced.
Great acronym-dropping, but I'm afraid you have no idea what you're talking about. In a vanilla WEP implementation, all users have to know the shared key of the network, which means that any user has sufficient knowledge to masquerade as the network itself. More modern schemes, like Cisco's, allow the network to authenticate itself to the user (and vice versa), and then provide a per-user key. This prevents the sort of deception (poorly) described in the article.
"SSL Gateway"? SSL doesn't have anything to do with it. Do you mean IPSEC, or some other tunnel-based security? Or do you mean encapsulating GSM traffic within an SSL connection? That's not exactly a simple solution.
I know this is a troll, but the original question didn't seem to be.
Dosemu predated VMWare by several years. IBM's various VM systems predated VMWare by decades. Intel's VM86 mode for machine virtualization came with the 80386, long before VMWare was a twinkle in its creator's eye.
It's not the concept of virtualizing a machine that's valuable. It's the quality of the implementation. VMWare's hard to beat on those grounds.
Slashdot Mirror
802.11b/g also use spread spectrum techniques, so that part's hardly new.
Gosh, like PostgresQL or Oracle?
And plenty of people who are using it quite happily. See EarthLink's SpamBlocker for a related approach that uses a kind of challenge to help the user populate his whitelist / address book.
There's always plenty of documentation on why something is a really bad idea. "'Considered Harmful' Considered Harmful". I clean out my spam folder once a week or more, and haven't found fewer than 1000 messages in it, usually 2000, for as long as I can remember. These are desperate times.
The CLR is a stack-based virtual machine. .NET languages are first compiled into (MS)IL, which is the code for that Virtual Machine. Upon execution the JIT compiler translates the IL operations of the virtual machine into native code for the actual target machine.
.NET's poorly marketed predecessor systems?
What exactly do you think VM means? Are you perhaps reacting to the nasty connotations from
It's great that MS has technology which can make all code "blazing". That'll save me a lot of time optimizing some of the cretinous code I have to deal with.
There are effective approaches to reducing footprint that have nothing to do with when the bytecode is turned into native code. Tree-shaking is one that worked for Lisp and similar systems. (That does require static ahead-of-time program *analysis*, but that's different.) Sharing VMs for different programs is another.
The downside is that you may lose some of the dynamic capabilities of the language.
It was a parody, right?
A transaction can provide the ACID properties throughout the duration of the transaction. Most importantly for read-only operations, you have Isolation. Isolation let you perform your queries without being affected by ongoing writes.
This is better than a lock, which another poster suggested, as a lock will block all writers, while a transaction need not block anybody.
Millions of phones can access the web: most of them can do WAP/WML or its forebears, some of them WMLScript, some of them HTML 4 or some subset, but only tiny minority that can run any Javascript. Vastly more phones can run Java (J2ME) MIDlets than can execute Javascript. And, no, most websites don't perform terribly well on a phone.
Furthermore, there's nothing in the HTML standards that requires Javascript. I'm not sure where you got that idea.
It's great that your phone can do Javascript. You can't really reason about the rest of reality from that fluke.
Some other guy has written some other tiny little app with limited appeal. How is this news? He uses XHTML?
Say, I have a program that calculates the specific density and body fat percentage of my cats...and you can access it via the WORLD WIDE WEB! Oh, yeah, and everything is first output into XML 1.1, then transformed by an XSLT stylesheet into XSL:FO, which is then rendered into PDF with embedded Javascript, which I then transform into WBMP for output to my cell phone through WAP Push. Every five minutes I also receive updates via animated MMS messages, and my car's 802.11 telematic system has a holographic heads-up display of the instantaneous fat accumulation rate of each feline, broken down topologically. When it drops below a threshold determined by an expert system, which is accessed via the venerable ELIZA protocol, a fiber optic quantum-encrypted transmitter activates a remote twinkie feeder device to compensate. Um...I think the twinkies might contain carbon nanotubes or buckyball-nougat or something.
I'm porting the whole system to be C# running on Mono-current running on Parrot running on FreeBSD running on VMWare running on Linux running on my home-built liquid-cooled micro form factor Opteron multimedia PC.
Sheesh.
There's a difference between (allegedly) idly speculating about something and actually doing something about proving or disproving it...or in this case, exploring the idea in excruciating detail.
> TCP is a layer above IP which is (drum roll please).... ALL IN SOFTWARE
I suggest you look at any number of modern router implementations, and more to the point, TCP and IPSEC "offload" network cards from 3com, Adaptec, Alacritech, and others. For that matter, decent ethernet NICs have been doing checksumming in the hardware for aeons now.
(Of course, this has nothing to do with Fast TCP.)
As somebody who works for a company who was minding its own business when the boys in Blue showed up waving patent claims at us, I have to say that IBM doesn't just defend itself with its alleged IP. It's out there beating the bushes for victims.
Intel and AMD do provide hardware RNGs.
. ht m
r ma tion/0,,30_118_756_3734%5E873%5E4366,00.html
http://www.intel.com/design/security/rng/rnghow
http://www.amd.com/us-en/Processors/ProductInfo
Linux already has support for the Intel, AMD, and VIA generators.
Right, a dictionary attack would never, ever guess jester2. I mean, it's a dictionary word PLUS A SINGLE DIGIT NUMBER! If you could see the mail logs on any major ISP's servers during a spam dictionary attack, you'd know that spammers will blindly try a great number of combinations.
Furthermore, I had a similar problem with an e-mail address that I know wasn't sold because I was the one hosting it. It turns out that somehow I had taken some spyware onboard, and it was sending all my form submissions to some unscrupulous collector.
(Yes, I use Linux, too; no, it can't replace Windows for everything I need to do.)
Blocking mail from small sites using dynamic DNS is also a useful tool. No single tool in the effort to stop spam is sufficient, nor are most of them painless.
The industry is considering several anti-spam measures that would form a "web of trust" between SMTP senders. The burden of joining that web of trust will likely be too high for Joe Linux User, just as hosting a permanent SSL/TLS-protected site with a *valid* site certificate is generally too much trouble for a home access user.
If you want your mail to be accepted, smarthost it to your upstream provider or to any major mail provider that provides SMTP relay services. Their relays had better be authenticated, of course, because ISPs will continue to crack down on mail through open relays.
Used for ROM? What do you think they're storing in there?
The 4 gibibyte per-process RAM limit is a limitation of some operating systems, and it's not always 2GiB. A 32-bit processor can address 4GiB just fine. As has been mentioned, with segmentation or bank-swapping techniques like PAE. It's distasteful, but it can be useful in some applications.
No, it's 4 GiB exectly.
http://physics.nist.gov/cuu/Units/binary.html
This is why the hard drive manufacturers aren't lying to you; your OS is.
riggirds,
-- Robert
There's nothing terribly wrong with RC4. I hate to see its good name sullied like this. It's cheap, well-understood, and widely implemented. If you're accessing a web page with SSL/TLS, you're probably using the RC4 cipher.
As you say, the major problem with WEP's use of RC4 was in the selection of weak IV's. The other major issue was in key management. If long-lived, shared, static keys are replaced with short-lived, individual keys for unicast traffic, the security of WEP is greatly enhanced.
-- Robert
Great acronym-dropping, but I'm afraid you have no idea what you're talking about. In a vanilla WEP implementation, all users have to know the shared key of the network, which means that any user has sufficient knowledge to masquerade as the network itself. More modern schemes, like Cisco's, allow the network to authenticate itself to the user (and vice versa), and then provide a per-user key. This prevents the sort of deception (poorly) described in the article.
"SSL Gateway"? SSL doesn't have anything to do with it. Do you mean IPSEC, or some other tunnel-based security? Or do you mean encapsulating GSM traffic within an SSL connection? That's not exactly a simple solution.
-- Robert
I know this is a troll, but the original question didn't seem to be. Dosemu predated VMWare by several years. IBM's various VM systems predated VMWare by decades. Intel's VM86 mode for machine virtualization came with the 80386, long before VMWare was a twinkle in its creator's eye. It's not the concept of virtualizing a machine that's valuable. It's the quality of the implementation. VMWare's hard to beat on those grounds.
Pardon me, but wouldn't the "interesting bit" be that it's a frickin' SIX-LEGGED ROBOTIC BRAIN SURGEON?