There were lots of good reasons to use SuSE until version 7.3. But this is not true anymore with version 8.0: they have removed support for the original YaST installation tool.
As a result, the users are now forced to use YaST 2, which depends on Qt. So far, I have managed to install all my PCs without the Qt libraries (this is a personal choice because I prefer GTK+, not something that I recommend) using the original YaST. In the 7.x versions, YaST was issuing some warnings saying that Qt was a necessary component and that it should be installed anyway, but I could safely ignore this warning and get a fully working system without it. It looks like this is not possible anymore with SuSE 8.0.
I have used every single release of SuSE Linux since version 4.3 several years ago, and I praised them for their excellent installation and internationalization. But now it looks like I will have to select another distribution if I do not find a way to bypass YaST 2. :-(
Moderators note: this is intended to be a public complaint, not a flame. But if you think that it should be moderated as Flamebait because you disaprove my choice of toolkits, then feel free to do it.
This article seems to raise more questions than it attempts to answer... This is not surprising because the "programmer productivity" has been the subject of many debates.
The proposed definition ("Ability to solve customer problems quickly") seems to ignore several of the good points mentioned earlier. For example, one can be able to solve a customer's problem quickly with an ugly hack. Some undocumented spaghetti code full of black magic may be able to solve one problem quickly, but it would be impossible for anyone to maintain this code later. Or to re-use it for solving someone else's problem.
So who is more productive? The one who solved the problem quickly with an ugly hack or the one who solved the same problem by writing clean, documented and re-usable code?
So it is a pity that what appears to be the conclusion of this article has thrown away the notion of clean and well-documented code mentioned earlier. Maybe a better (but more complex) definition would be: "Ability to solve customer problems quickly and to solve future, similar, problems in a quicker way". The drawback of this definition is that it cannot be measured on the current project, but only when the next one appears.
It doesn't seem to display correctly in ns4. I had to use "view source" in order to read any of the text and get the url of the pictures.
Probably you need to double check your table html.
This is not only a problem with Netscape. The HTML code of the page is broken: there is a <table> tag at the beginning of the page and it is never closed. The table structure is incorrect anyway, because the <table> tag is immediately followed by <td> without a <tr>. The same problem occurs for a <center> tag and a <font> tag that are never closed (besides, the <font> tag occurs just before a block-level <h2> tag, so it should have no effect). Also, all color specifications are incorrect: missing quotes, missing "#" sign before the hex values.
MrP-, if you are mirroring this slashdotted page, it would be a public service to fix the most obvious errors so that the mirrored page can be viewed by most browsers and passes at least some minimal HTML validation tests. The easiest way to fix the problem would be to remove the offending tags (2nd, 3rd and 4th line in the original page).
I do not think that many spammers pay attention to the delivery time for their test messages, because they usually send dozens or hundreds of probes at the same time. As long as the message is delivered (by hand) within a couple of hours, that should be sufficient.
But they will probably pay attention to this trick sooner or later. So we need a more sophisticated script than this simple "sendmail -bd". Maybe some kind of "limited open relay": a program that always delivers the first message received from any IP address, but delays (or drops) all the other ones coming from the same address. There could be a configurable threshold allowing more than one message per IP, in order to fool the spammers who would try to send two test messages.
Such a machine could be used as an open relay, but with limited consequences. As long as the administrator of the machine keeps the logs of all incoming IP addresses (with timestamps and as many details as possible), the messages that go through it will not do much damage.
I wonder how useful they would be in a honey pot setup, if you had the bandwidth to spare.
They perform two very different purposes: the poisoning scripts mentioned above are designed to fool the robots that harvest e-mail addresses. They slow down the spammers and introduce many invalid addresses in their list, but they cannot completely prevent the spammers from collecting e-mail addresses.
The fake open relays mentioned in the article are designed to stop the spammers from sending their spam. The spammers think that they have found a nice open SMTP relay and they dump all their spam to it, but in the end nothing is sent to the intended recipients.
You could of course run both on the same machine, but this is probably not a good idea because the goals of these spam traps is to convince the spammers that they have found a "live one". If there is anything that looks strange on the target site (such as a warning generated by their harvesting robot), it is likely that they would consider this to be a suspicious site and they would not try to use it to relay their spam.
But now it is largely a duplication of efforts. Granted its pie in the sky, but imagine how far
along the linux desktop would be if all those developers coded for one and not two projects.
You are assuming that all developers who work separately on GNOME and KDE could have moved to a single project and made the resulting destkop better and faster. This is probably not true.
It is likely that some developers who are working on GNOME or KDE now would not be working on any desktop project if the only choice had been the other destkop environment. There are some significant technical and conceptual differences between both projects and some programmers are much more likely to contribute to a project that fits the way they think. The first difference is in the programming languages: although both projects use object-oriented concepts, the GNOME libraries are written in C (which makes it easier to add bindings for other languages such as Perl or Python) and the KDE libraries are written in C++ (which makes the development faster if you stick to C++). This is just an example; there are many other differences in the architecture of both systems.
The problem is how do you tell someone who codes for free what they should work on?
Nobody should tell them. They should work on whatever they feel comfortable with. Some developers will prefer GNOME because they prefer the way the GNOME libraries are designed. Some of them will prefer KDE because they prefer the way the KDE libraries are designed. There are not so many experienced programmers who would feel equally at home in both environments. So let them choose whatever they want and work on what they like best. There is not much duplication of effort anyway.
Wouldn't you need more prey than predators to obtain a viable population?
Only if the predator is bigger or needs more energy than the prey. This is the case for foxes and rabbits or wolves and sheep, but sometimes there are many more predators than preys. Consider the following pairs of preys and predators:
Dogs, cats and ticks
Humans and moskitos (although sometimes the human is the predator)
Slashdot and slashdotters
It would have been more appropriate to call the robots "parasites" instead of "predators", because that's what they really are. Predators usually kill their preys. Parasites feed from their preys without killing them (usually). These robots behave more like parasites.
There is one thing that you did not mention and that is important for many OpenSource projects: weakly connected clients.
Many contributors to OpenSource projects are doing their development at home. Although some of them have a cable or xDSL connection, many others are still using a slow modem and an expensive telephone line (especially outside the US). A good SCM system for OpenSource projects should therefore support these weakly connected users as well as possible.
CVS is far from ideal, but not too bad from that point of view because you can work for a while in your local tree and then update/commit without transmitting too much data on the network. Systems like Rational ClearCase require a specific setup and different clients (Attaché) for that.
With CVS and some other systems, it is even possible for someone who has no direct connection to the Internet to get/checkout only a small part of the tree (or individual files) on some computer that is connected to the Internet (at work or at school) and then take the files at home, modify them and upload the changes. This is possible because you can easily remember or write down the names (and optionally the versions) of the files that you want to fetch with CVS. I think that the proposed "arch" system is worse than CVS in this case.
It's a pity that you were moderated offtopic, because this was very much related to the LILO boot sreens.
Short explanation for those who haven't looked at my pages yet: the first two animated boot screens that I created were based on an X-Ray scan of an Apple Titanium G4 (because this was the only X-Ray image of a laptop that I could find). It would be nice to be able to animate the X-Ray scan of some x86 laptop because that would be more appropriate than the Apple Tibook, which does not use LILO.
This comment is very appropriate but wrong (and it is off-topic, just like this reply). I am the author of the page mentioned in this story, and I come from Belgium, not from France.
And everybody knows that the French Fries should be called Belgian Fries...
let us play xbill on the boot screen. If Bill wins, the system boots Windows. If I win, I get my Linux back.
Interesting idea, but difficult to implement because the mouse is not available in LILO so it would be hard to play XBill.
But maybe it would be possible to design a similar game with keyboard input only? If you have some ideas, feel free to send them to me and I will see if I can implement them easily. Or even better: implement the LILO version of XBill yourself and publish it so that everybody can have fun!
That page explains how to make a static splash screen for the old LILO, using the program mklilomsg. This is different from the animated splash screens that can be made with the patched version of LILO included in SuSE Linux (and hopefully someday in the standard LILO) using the program mkbootmsg.
Programming the animated splash screens is very different, because they require a special script file that defines how the menu is drawn, how the keyboard input is processed, how the various animated bits are displayed on the screen, and so on... This is more work than for a static image, but the result is much more interesting.
SuSE LILO required (was Re:Breakout suggestion)
on
Animate Your LILO
·
· Score: 5, Informative
Yes, you do need the SuSE version of LILO because this is the only version that includes support for callback functions and timer events. This is mandatory for making the animations work. All other versions of LILO can only display static images and do not let you choose where the menu is displayed, how the keyboard input should be handled, and so on.
As a matter of fact, my plan is to release the "breakout" boot screen in two versions:
The normal version would allow you to select any operating system and to boot at any time
The "game freak" version (a.k.a. "waste of time" version) would not let you boot your computer until you have passed at least the first level. If you want to select the second OS in the list, then you would have to pass the second level, and so on...
I could even release an even nastier version that would not let you boot anything until you have passed all levels. Then you would really have to think twice before rebooting... <evil grin>
P.S.: my site seems to be/.ed for the moment. I suggest that you wait until tomorrow before downloading these boot screens, in order to save some bandwidth today. In the meantime, I encourage you to visit 3D Gamers and have some fun.
I have quickly edited my web pages to add the correct links. My web pages were designed to automatically give you the most appropriate version (depending on the language settings in your browser, as explained on this page). It's a pity that thimoty has posted the links that go to the French-only version of my pages.
It's a pity that the links posted in the story point to the French version of my pages because I wrote them first in English. If you had taken a minute to try the little button in the top right corner of my pages (the one with the English/French flag), you would have seen that you can easily switch between the English and French versions.
Posting a link to the automatic translation of a page that was already translated from English to French is a nice way to waste your time... (but that's the point of these LILO boot screens anyway, so maybe you are not completely wrong).
That article was mentioned in Risks Digest 21.87 (see the newsgroup comp.risks). Exploding chips are a dangerous idea. You would not like them to be triggered by accident...
I do not think that the site crashed under the Slashdot effect. I tried loading the page using Netscape 4.78 for Solaris. And I got the exact same error message:
Microsoft VBScript runtime error '800a000d'
Type mismatch: '[string: ""]'
/x/inc/get_guid.asp, line 10
However, just before getting this error displayed in the main window, I saw a little JavaScript warning in the status bar. So there are problems in their code, and maybe someone is trying to fix these errors as we are writing this...
Reloading the page two minutes later shows some content, but there are still some JavaScript warnings. I opened the JavaScript console in Netscape by typing "javascript:" in the location bar, and I saw the following errors displayed in the window:
JavaScript Error: http://www.saltlake2002.com/x/inc/get_guid.asp,
line 1:
syntax error.
<html>
^
JavaScript Error:
http://a799.ms.akamai.net/3/799/388/cf806351e98dbd/www.saltlake2002.com/x/js/stdframe.js,
line 131:
bShowAds is not defined.
Their JavaScript code is far from perfect... They probably tested it only with MSIE and were happy with the result, so they published the site. Don't they know that other browsers and other operating systems exist?
Now this is interesting... My previous comment (parent of this one) was slightly wrong because the solution proposed by this company works differently. They use some FEC method that is better than Reed-Solomon codes, as I discovered later by reading their detailled technical documentation (available in their technology library.)
But I cannot understand why my comment which proposed a different method was rated three times as "Overrated (-1)", while its parent was rated twice as "Interesting (+1)". I do not understand why three different moderators would give exactly the same moderation, especially when the comment was already scored at 0 and the article contains many other comments could have been moderated up or down.
The technique used by Digital Fountain is called Forward Error Correction.
Several Forward Error Correction techniques are used in cellular networks, for example. If you have a GPRS or (soon) UMTS phone, it is already using some of the techniques that appear to be incredibly advanced if you read the EETimes article. But in fact, all these things are well known. I think that several DAB/DVB (Digital Audio/Video Broadcasting) protocols do the same as well.
In essence, is not this the same as file compression?
Yes, this sounds very much like yet another compression method. Anyone who knows a bit about information theory will immediately ignore this marketroid talk about mathematical equations and go straight to the conclusion that the are using some proprietary compression algorithm.
But they are doing a bit more than compression. They claim that the receiving side does not care about the order in which the packets arrive. Big deal. You only have to use a sequence number to re-order the packets after receiving them. 16 bits should be more than enough for that.
So let's see how this could be done without all this marketing smokescreen:
Send some packets to the other side with path MTU discovery enabled in order to know how large your UDP packets can be.
Compress your data using a well-known algorithm such as deflate/gzip (or something more agressive if your CPU is much faster than your network).
Send your stuff to the other side, sacrificing about 0.4% of the bandwidth for a 2-bytes sequence number (assuming that the packet size is about 500 bytes, but it could be much more).
The receiver gets the data, re-orders it as
appropriate, and maybe sends a selective ARQ when it detects some missing packets (but these can be sent in batches, and only if 100 or 1000 other packets have been received without any trace of the missing ones).
There is nothing magic about their solution. Some of these techniques (especially the reduction of the number of ACKs) have been proposed to the IETF as extensions to TCP.
But the solution that is proposed by this company could do more harm than good. They are using UDP instead of TCP in order to avoid the TCP-friendly rate control. This is fine as long as they are alone on their network segment, but this is a really bad idea if this solution is deployed on the Internet. Hopefully the price tag (between $70,000 and $150,000) will discourage many users.
Michael says : "completely open any time you browse the web with IE. "
Story says "who view a specially constructed Web page"
Both of these sentences are right and there is no contradiction between them. "browsing the web" assumes that you are viewing several web pages. A "specially constructed web page" may have been created by a worm or a Trojan horse. This means that even if you only browse "trusted" sites, you are completely open to any attack involving this IE bug, because these sites may have been infected by the worm.
From what I could read in the Bugtraq discussions, it looks like it should not be hard for a black hat to write a worm that exploits this IE bug and modifies any ASP pages that it could find on the same machine (or other Windows hosts that have open shares). Once the web server is modified in that way, it would propagate the worm further and infect other IE users.
If you think that this scenario is unrealistic, please think about how Code Red and Nimda have been infecting millions of Windows computers recently.
And if you think that you are safe browsing Slashdot, think about what would happen if the OSDN ads server was infected...
Slashdot Mirror
There were lots of good reasons to use SuSE until version 7.3. But this is not true anymore with version 8.0: they have removed support for the original YaST installation tool.
As a result, the users are now forced to use YaST 2, which depends on Qt. So far, I have managed to install all my PCs without the Qt libraries (this is a personal choice because I prefer GTK+, not something that I recommend) using the original YaST. In the 7.x versions, YaST was issuing some warnings saying that Qt was a necessary component and that it should be installed anyway, but I could safely ignore this warning and get a fully working system without it. It looks like this is not possible anymore with SuSE 8.0.
I have used every single release of SuSE Linux since version 4.3 several years ago, and I praised them for their excellent installation and internationalization. But now it looks like I will have to select another distribution if I do not find a way to bypass YaST 2. :-(
Moderators note: this is intended to be a public complaint, not a flame. But if you think that it should be moderated as Flamebait because you disaprove my choice of toolkits, then feel free to do it.
This article seems to raise more questions than it attempts to answer... This is not surprising because the "programmer productivity" has been the subject of many debates.
The proposed definition ("Ability to solve customer problems quickly") seems to ignore several of the good points mentioned earlier. For example, one can be able to solve a customer's problem quickly with an ugly hack. Some undocumented spaghetti code full of black magic may be able to solve one problem quickly, but it would be impossible for anyone to maintain this code later. Or to re-use it for solving someone else's problem.
So who is more productive? The one who solved the problem quickly with an ugly hack or the one who solved the same problem by writing clean, documented and re-usable code?
So it is a pity that what appears to be the conclusion of this article has thrown away the notion of clean and well-documented code mentioned earlier. Maybe a better (but more complex) definition would be: "Ability to solve customer problems quickly and to solve future, similar, problems in a quicker way". The drawback of this definition is that it cannot be measured on the current project, but only when the next one appears.
This is not only a problem with Netscape. The HTML code of the page is broken: there is a <table> tag at the beginning of the page and it is never closed. The table structure is incorrect anyway, because the <table> tag is immediately followed by <td> without a <tr>. The same problem occurs for a <center> tag and a <font> tag that are never closed (besides, the <font> tag occurs just before a block-level <h2> tag, so it should have no effect). Also, all color specifications are incorrect: missing quotes, missing "#" sign before the hex values.
MrP-, if you are mirroring this slashdotted page, it would be a public service to fix the most obvious errors so that the mirrored page can be viewed by most browsers and passes at least some minimal HTML validation tests. The easiest way to fix the problem would be to remove the offending tags (2nd, 3rd and 4th line in the original page).
I highly recommend checking the page with HTML Tidy or with the W3C validator.
I do not think that many spammers pay attention to the delivery time for their test messages, because they usually send dozens or hundreds of probes at the same time. As long as the message is delivered (by hand) within a couple of hours, that should be sufficient.
But they will probably pay attention to this trick sooner or later. So we need a more sophisticated script than this simple "sendmail -bd". Maybe some kind of "limited open relay": a program that always delivers the first message received from any IP address, but delays (or drops) all the other ones coming from the same address. There could be a configurable threshold allowing more than one message per IP, in order to fool the spammers who would try to send two test messages.
Such a machine could be used as an open relay, but with limited consequences. As long as the administrator of the machine keeps the logs of all incoming IP addresses (with timestamps and as many details as possible), the messages that go through it will not do much damage.
You are probably refering to Sugarplum or Wpoison.
They perform two very different purposes: the poisoning scripts mentioned above are designed to fool the robots that harvest e-mail addresses. They slow down the spammers and introduce many invalid addresses in their list, but they cannot completely prevent the spammers from collecting e-mail addresses.
The fake open relays mentioned in the article are designed to stop the spammers from sending their spam. The spammers think that they have found a nice open SMTP relay and they dump all their spam to it, but in the end nothing is sent to the intended recipients.
You could of course run both on the same machine, but this is probably not a good idea because the goals of these spam traps is to convince the spammers that they have found a "live one". If there is anything that looks strange on the target site (such as a warning generated by their harvesting robot), it is likely that they would consider this to be a suspicious site and they would not try to use it to relay their spam.
You are assuming that all developers who work separately on GNOME and KDE could have moved to a single project and made the resulting destkop better and faster. This is probably not true.
It is likely that some developers who are working on GNOME or KDE now would not be working on any desktop project if the only choice had been the other destkop environment. There are some significant technical and conceptual differences between both projects and some programmers are much more likely to contribute to a project that fits the way they think. The first difference is in the programming languages: although both projects use object-oriented concepts, the GNOME libraries are written in C (which makes it easier to add bindings for other languages such as Perl or Python) and the KDE libraries are written in C++ (which makes the development faster if you stick to C++). This is just an example; there are many other differences in the architecture of both systems.
Nobody should tell them. They should work on whatever they feel comfortable with. Some developers will prefer GNOME because they prefer the way the GNOME libraries are designed. Some of them will prefer KDE because they prefer the way the KDE libraries are designed. There are not so many experienced programmers who would feel equally at home in both environments. So let them choose whatever they want and work on what they like best. There is not much duplication of effort anyway.
Only if the predator is bigger or needs more energy than the prey. This is the case for foxes and rabbits or wolves and sheep, but sometimes there are many more predators than preys. Consider the following pairs of preys and predators:
It would have been more appropriate to call the robots "parasites" instead of "predators", because that's what they really are. Predators usually kill their preys. Parasites feed from their preys without killing them (usually). These robots behave more like parasites.
There is one thing that you did not mention and that is important for many OpenSource projects: weakly connected clients.
Many contributors to OpenSource projects are doing their development at home. Although some of them have a cable or xDSL connection, many others are still using a slow modem and an expensive telephone line (especially outside the US). A good SCM system for OpenSource projects should therefore support these weakly connected users as well as possible.
CVS is far from ideal, but not too bad from that point of view because you can work for a while in your local tree and then update/commit without transmitting too much data on the network. Systems like Rational ClearCase require a specific setup and different clients (Attaché) for that.
With CVS and some other systems, it is even possible for someone who has no direct connection to the Internet to get/checkout only a small part of the tree (or individual files) on some computer that is connected to the Internet (at work or at school) and then take the files at home, modify them and upload the changes. This is possible because you can easily remember or write down the names (and optionally the versions) of the files that you want to fetch with CVS. I think that the proposed "arch" system is worse than CVS in this case.
It's a pity that you were moderated offtopic, because this was very much related to the LILO boot sreens.
Short explanation for those who haven't looked at my pages yet: the first two animated boot screens that I created were based on an X-Ray scan of an Apple Titanium G4 (because this was the only X-Ray image of a laptop that I could find). It would be nice to be able to animate the X-Ray scan of some x86 laptop because that would be more appropriate than the Apple Tibook, which does not use LILO.
This comment is very appropriate but wrong (and it is off-topic, just like this reply). I am the author of the page mentioned in this story, and I come from Belgium, not from France.
And everybody knows that the French Fries should be called Belgian Fries...
Interesting idea, but difficult to implement because the mouse is not available in LILO so it would be hard to play XBill.
But maybe it would be possible to design a similar game with keyboard input only? If you have some ideas, feel free to send them to me and I will see if I can implement them easily. Or even better: implement the LILO version of XBill yourself and publish it so that everybody can have fun!
Thanks for the idea! I had not thought about that... Maybe I will try to implement it.
But who would use a version of LILO that boots an OS (almost) at random?
That page explains how to make a static splash screen for the old LILO, using the program mklilomsg. This is different from the animated splash screens that can be made with the patched version of LILO included in SuSE Linux (and hopefully someday in the standard LILO) using the program mkbootmsg.
Programming the animated splash screens is very different, because they require a special script file that defines how the menu is drawn, how the keyboard input is processed, how the various animated bits are displayed on the screen, and so on... This is more work than for a static image, but the result is much more interesting.
Yes, you do need the SuSE version of LILO because this is the only version that includes support for callback functions and timer events. This is mandatory for making the animations work. All other versions of LILO can only display static images and do not let you choose where the menu is displayed, how the keyboard input should be handled, and so on.
This is explained on my help page.
By the way, if you go to a SuSE mirror site to download the required packages, you will find:
Have fun, but please read the warnings on my help page before playing with LILO.
As a matter of fact, my plan is to release the "breakout" boot screen in two versions:
I could even release an even nastier version that would not let you boot anything until you have passed all levels. Then you would really have to think twice before rebooting... <evil grin>
P.S.: my site seems to be /.ed for the moment. I suggest that you wait until tomorrow before downloading these boot screens, in order to save some bandwidth today. In the meantime, I encourage you to visit 3D Gamers and have some fun.
Oops, sorry.... The third link should have been:
And I even looked at the Preview before posting... X-)
I have quickly edited my web pages to add the correct links. My web pages were designed to automatically give you the most appropriate version (depending on the language settings in your browser, as explained on this page). It's a pity that thimoty has posted the links that go to the French-only version of my pages.
The correct links should have been:
The site is hit rather badly by the Slashdot effect... You will have to be patient...
Ha ha ha... Thanks for the laugh!
It's a pity that the links posted in the story point to the French version of my pages because I wrote them first in English. If you had taken a minute to try the little button in the top right corner of my pages (the one with the English/French flag), you would have seen that you can easily switch between the English and French versions.
Posting a link to the automatic translation of a page that was already translated from English to French is a nice way to waste your time... (but that's the point of these LILO boot screens anyway, so maybe you are not completely wrong).
You could also make it explode... See for example this article in New Scientist:
http://www.newscientist.com/news/news.jsp?id=ns999 91795
That article was mentioned in Risks Digest 21.87 (see the newsgroup comp.risks). Exploding chips are a dangerous idea. You would not like them to be triggered by accident...
I do not think that the site crashed under the Slashdot effect. I tried loading the page using Netscape 4.78 for Solaris. And I got the exact same error message:
However, just before getting this error displayed in the main window, I saw a little JavaScript warning in the status bar. So there are problems in their code, and maybe someone is trying to fix these errors as we are writing this...
Reloading the page two minutes later shows some content, but there are still some JavaScript warnings. I opened the JavaScript console in Netscape by typing "javascript:" in the location bar, and I saw the following errors displayed in the window:
Their JavaScript code is far from perfect... They probably tested it only with MSIE and were happy with the result, so they published the site. Don't they know that other browsers and other operating systems exist?
Now this is interesting... My previous comment (parent of this one) was slightly wrong because the solution proposed by this company works differently. They use some FEC method that is better than Reed-Solomon codes, as I discovered later by reading their detailled technical documentation (available in their technology library.)
But I cannot understand why my comment which proposed a different method was rated three times as "Overrated (-1)", while its parent was rated twice as "Interesting (+1)". I do not understand why three different moderators would give exactly the same moderation, especially when the comment was already scored at 0 and the article contains many other comments could have been moderated up or down.
Several Forward Error Correction techniques are used in cellular networks, for example. If you have a GPRS or (soon) UMTS phone, it is already using some of the techniques that appear to be incredibly advanced if you read the EETimes article. But in fact, all these things are well known. I think that several DAB/DVB (Digital Audio/Video Broadcasting) protocols do the same as well.
Yes, this sounds very much like yet another compression method. Anyone who knows a bit about information theory will immediately ignore this marketroid talk about mathematical equations and go straight to the conclusion that the are using some proprietary compression algorithm.
But they are doing a bit more than compression. They claim that the receiving side does not care about the order in which the packets arrive. Big deal. You only have to use a sequence number to re-order the packets after receiving them. 16 bits should be more than enough for that.
So let's see how this could be done without all this marketing smokescreen:
There is nothing magic about their solution. Some of these techniques (especially the reduction of the number of ACKs) have been proposed to the IETF as extensions to TCP.
But the solution that is proposed by this company could do more harm than good. They are using UDP instead of TCP in order to avoid the TCP-friendly rate control. This is fine as long as they are alone on their network segment, but this is a really bad idea if this solution is deployed on the Internet. Hopefully the price tag (between $70,000 and $150,000) will discourage many users.
Both of these sentences are right and there is no contradiction between them. "browsing the web" assumes that you are viewing several web pages. A "specially constructed web page" may have been created by a worm or a Trojan horse. This means that even if you only browse "trusted" sites, you are completely open to any attack involving this IE bug, because these sites may have been infected by the worm.
From what I could read in the Bugtraq discussions, it looks like it should not be hard for a black hat to write a worm that exploits this IE bug and modifies any ASP pages that it could find on the same machine (or other Windows hosts that have open shares). Once the web server is modified in that way, it would propagate the worm further and infect other IE users.
If you think that this scenario is unrealistic, please think about how Code Red and Nimda have been infecting millions of Windows computers recently.
And if you think that you are safe browsing Slashdot, think about what would happen if the OSDN ads server was infected...
No. If I am not mistaken, the story goes like this:
8080--->8088/8086 -> *x86 (Intel)
\-->Z80 (Zilog)
With various extended and enhanced such as the Z80A from Zilog (faster version) or the 8088-2 from Intel (the one I had in my first PC).