LinkSys added stateful packet inspection in a recent firmware update (listed as SPI on the configuration). I havent't tested it, so I can't vouch for the implementation.
You can use it for business and have fun with it! It's two! Two operating systems in one!
Seriously, back in the good old days (circa 1980) IBM's VM/370 OS was "available source", and we used to play with and modify it. Some of those modifications even got picked up by IBM. We also used it for business (the customer of those modifications).
There's (obviously) nothing to stop businesses from exploiting the benefits provided by those that play with the OS.
And, as long as there's source, there's nothing to stop people from continuing to play.
The idea of identifying the abusing traffic, and throttling it back to the source sounds like closed loop congestion control.
It's a concept that has existed in Frame Relay/ATM, for example, for a decade (at least on StrataCom/Cisco) equipment. They use an algorithm called ForeSight(tm) on their core switches to throttle VC traffic in the case of congestion at the source. This later evolved into the ATM ABR standard, with input from other vendors.
In this type of automatic "biological" response, as long as no other traffic is attempting to use the bandwidth, the activity is permitted (who knows, it could be a "normal burst"). When other traffic is active, the offender is throttled back to to the source to its minimum rate.
While it doesn't stop the problem, it makes the offender ineffective at impacting service. As a result, it's no longer a "denial of service". Some more information on ForeSight and ABR in this whitepaper.
The functionality predates the BPX product mentioned in the whitepaper (the StrataCom IPX had it), but that's before Cisco purchased StrataCom.
Frame and ATM are "session oriented"; a PVC or SVC defined the communications along a path, so it's easy to define the parameters to control traffic characteristics.
I'm not that familiar with IP QOS; is there an equivalent functionality that would apply? If so, could the problem be solved by making the attack "unattractive" (nondisruptive)?
Can someone comment on why these fuel cells use methanol instead of isopropyl alcohol? Is it a matter of efficiency, or is the reaction not acceptable for some reason (e.g., byproducts, manufacturing process)?
Isopropyl is much more easily available (most hotel gift shops even carry it, not to mention every grocery and drug store). If the fuel cells were consumer refillable with isopropyl, they would be accepted by the market much more easily.
"In a demonstration for Reuters, a prototype -- roughly the size of a dishwasher -- was run for around 10 minutes using four 12-volt car batteries as an initial power source. Emitting a steady motorized hum, the machine powered three 100-watt light bulbs for the duration."
It sounds like the box contained a bunch more batteries, and a DC-to-AC inverter (the "hum"). If the box contains 5 12V batteries, the 4 external batteries would be charged (at least initially). The combination of 9 12VDC batteries, could keep 3 100 watt bulbs going for a long time (probably at least a day, enough to wear out any news reporter).
It doesn't sound like much of a trick from the description.
Regarding the Microsoft settlement, I don't believe that the current proposal provides adequate reparations to those injured by Microsoft's anti-competitive behavior. Hundred, even thousands, of small companies have ceased to exist over the decades because of Microsoft's business practices.
Similar to the settlement against AT&T, Microsoft should become a government regulated Monopoly, until its market share drops to an acceptable level (40%, for example, assuming one of it's competitors is now also at 40%). This must be true for all Microsoft product lines, before regulation is lifted.
Even after being found guilty of being an illegal monopoly, Microsoft's behavior has not changed. Regulation of their behavior, with the threat of severe criminal penalties for failure to comply, is the only remedy that I can see will curtail them. The market must be able to return to a state of competition.
Imagine the damage to the United States if Microsoft were to fail, as Enron failed. The risks of a monopoly are greater than merely the loss of competition.
If you're comparing Mhz, then you're right, it doesn't look very impressive. That's why you need to compare work performed per unit time.
Mainframe benchmarks are not performed like PC benchmarks; the idea it to completely remove (as much as possible) any constraint on the performance of the CPU (i.e., operate the CPU unconstrained). The measurement is solely the perform of the CPUs, and not the I/O subsystem.
The problem is that microcoded instructions operate like very complex instructions. It's somewhat like comparing CISC to RISC. In this case, the PC CPU (say, a P4) you are using as a base is actually the RISC CPU in the comparison.
MHz became very meaningless along time ago in the mainframe world. For a while, they had gone to adjusted MIPS (millions of instructions per second), based on an adjusted comparative value to an ancient mainframe. That fell apart about 15 years ago, and TPS (transactions per second; work per unit time) became the comparative measurement for judging the performance of a mainframe CPU. It's probably changed; I've been out of the field for 6+ years now.
If you wanted to compare a PC CPU like the P4 to a mainframe CPU, you would need to establish an "equal workload unit", then measure the number of workload units completed in a given interval by each processing complex operating unconstrained.
We spent 2 days just establishing and validating a baseline at the IBM Washington Systems complex for a benchmark about 10 years ago. It's not quite as simple as comparing the Mhz numbers.:-)
Even on home cable, it's not feasible. I had done this when I had gotten 1-2 scans a day. I never received a response to the report. A few trojans ago, the scan rate picked up (now over a dozen a day). It's gotten to the point where I just turn the monitoring for scans off (still watch for unauthorized access). This is just me at my home PC; it would be a full time job to keep up with this. It's just not feasible.
We need an automated tool for collecting the scan data, and depositing it in a repository. The respository can perform the correlations to track these to the source nodes. Higher level (towards core) IPSs can take the lower level (towards edge) ISPs off net until the DoS is terminated.
If done properly, but still mostly manual operation, a DoS would last at most an hour. The problem is getting cooperation between companies and organizations that are business competitors. You need a third party independant organization (jointly or government funded) to manage the repository and request the service deactivation.
Of course, then the repository would itself become the target for attack...
Mainframes have the largest (fastest) CPUs except for the class of supercomputers.
Benchmarking a mainframe involves standalone use, which is rarely accessible except when performing a benchmark. It is analogous to single user operation on Linux. You cannot obtain a performance measurement in a multiuser environment. It's like trying to get Quake FPS numbers while there are 200 other users logged into your Linux machine, doing who knows what. You'd be lucky to get two measurements the same, and neither would be valid.
The mainframe instruction set also contains incredibly complex instructions, which are microcoded. The SIE (start interpretive execution) instruction is an example. This single instruction handles the execution of a virtual machine in it's own unique environment (this is what handles running multiple Linux virtual machines on the same mainframe). This makes the concept of "MIPS" and "MHz" completely meaningless.
As a result, benchmarks concentrate on throughput: transactions per seconds or workload executions per unit time.
Someone else mentioned the I/O system on mainframes. The architecture is somewhat analogous to using a PostScript printer, from the 22,000 mile view. The CPU writes a program (channel program; a collection of CCWs -- channel command words). It transfers that to one of the, possibly multiple, dedicated I/O CPUs called IOPs (I/O Processors) in the mainframe with a single instruction. These IOPs in turn transfer operations to the dozens to hundreds of device controllers (over 1-16 of the possibly hundreds of parallel ~OC3 speed I/O channels), which are small I/O computers outside the mainframe. The controllers in turn talk to the actual devices (up to 32 per controller). There can be (and frequently are) thousands of devices attached to the mainframe at once (disk drives, communications controllers, printers, tape drives, etc.).
All I/O operations are asynchronous and essentially DMA. Much of the I/O error recovery is performed by the IOP and controllers without intervention from the main CPUs. In addition, misbehaving devices can be identified and recovered independantly, or isolated from the system. There's no such thing (barring a now very rare bug) as a malfunctioning device causing a system failure.
Memory bandwidth is very high as has been mentioned, but it's also multiported, multiplying the bandwidth. That is, memory is read and written to concurrently by multiple CPUs and IOPs.
The ideal mainframe environment is one in which the CPUs are running at about 80-85% average CPU utilization, 7x24x365. Enough headroom for peaks, but well utilized. The elimination of all bottlenecks in the processing complex is a required requisite to achieve this state. It's the ultimate hardware hacker/overclockers dream machine.
Exactly. Classical "users" don't upgrade their kernels from source. Those that do, should know that the MD5SUM is available. You can even make the MD5 verification part of the build process, it that is a concern:
# make
*** MD5UM file not found. Copy MD5 file "xyz"
from http://www.trustedsource.com to the kernel directory before performing a make.
This might not be a bad idea anyway, to keep people from becoming complacent.
It may be inefficient in space; but my cable can transfer at 600KBs (that K-Bytes, not bits) per second, because I am going to a "local" server in my cable company. It doesn't matter if a 22MB kernel becomes 60MB, I can still get it in under 2 minutes. And there are a lot of Usenet servers.
Asking for a big chunk of bandwidth and centralized management is the problem. It's expensive. Instead:
- Use the existing file sharing networks
- Netnews (I can get the file faster from my ISP's news server than anywhere else), and software like pan makes getting all the pieces trivial.
- Are there any open file sharing projects that we could use? Something that limited to a single download per user wouldn't be onerous. There are lots of cable/DSL linux users.
"Add a soupçon(?) of artificial intelligence and the suit could save its wearer if he is wounded. "You could send a command to take this guy home," says Stephen Jacobsen, CEO of Sarcos."
Uhh... first of all, my HS Prism is 72MB with the Memplug (with 64MB SmartMedia) and PiDirect. Yes, it works just like regular memory. It's great for keepin a couple of dozen full-length Linux manuals handy. Not to mention a dozen full-length novels, in case I get bored somewhere. Throw in a few dozen large databases for reference.
I don't know why people think that there is a lack of color applications; current versions all take advantage of the color display: iSilo, JFile, FireViewer, Mapopolis, HsPhoto Album, Planetarium, and loads of games (I've got 15 loaded right now).
DivX;) and MPEG4 support would be much more useful. As long as they have that, who would care if they also supported MS formats? My MP3 player supports Windows Media as well; that doesn't mean any of it will ever find its way into my equipment.
More importantly, do any DVD manufacturers plan to have flashable/upgradable machines (stick in a CD-R with a file called FLASHUPG.PAT and autoupgrade)? How about an "open" DVD player? You can alway have a ROM version of the software to fall back on for user errors...
Media formats are evolving too fast for the existing equipment to keep up; it locks consumers and media manufacturers into old technology.
Children do what children do; push buttons to establish limits. That's their job. Punish the managers and complacent sysadmins at the companies impacted, that allowed themselves to get a year behind on maintenance. There will always be children. We don't always have to be cheap/lazy about security. At least not if we're going to bitch and moan about stuff that's completely preventable.
If our government were properly e-enabled, including electronic instant runoff voting, then active participation would be much greater. Just take a look at the response the./ polls get:-)
...if the bad guys have a BlueTooth keyboard and/or mouse, since it's broadcasting every key stroke and mouse movement. A high gain directional antenna and amplifier will let them "target" a home miles away.
Slashdot Mirror
I don't think I've seen a better example that the DMCA stifles innovation than this.
LinkSys added stateful packet inspection in a recent firmware update (listed as SPI on the configuration). I havent't tested it, so I can't vouch for the implementation.
Seriously, back in the good old days (circa 1980) IBM's VM/370 OS was "available source", and we used to play with and modify it. Some of those modifications even got picked up by IBM. We also used it for business (the customer of those modifications).
There's (obviously) nothing to stop businesses from exploiting the benefits provided by those that play with the OS.
And, as long as there's source, there's nothing to stop people from continuing to play.
I thought amoebas didn't die, they just reproduced. Unless you arbitrarily end it's lifespan at the point it splits, wouldn't that make them older?
It's a concept that has existed in Frame Relay/ATM, for example, for a decade (at least on StrataCom/Cisco) equipment. They use an algorithm called ForeSight(tm) on their core switches to throttle VC traffic in the case of congestion at the source. This later evolved into the ATM ABR standard, with input from other vendors.
In this type of automatic "biological" response, as long as no other traffic is attempting to use the bandwidth, the activity is permitted (who knows, it could be a "normal burst"). When other traffic is active, the offender is throttled back to to the source to its minimum rate.
While it doesn't stop the problem, it makes the offender ineffective at impacting service. As a result, it's no longer a "denial of service". Some more information on ForeSight and ABR in this whitepaper. The functionality predates the BPX product mentioned in the whitepaper (the StrataCom IPX had it), but that's before Cisco purchased StrataCom.
Frame and ATM are "session oriented"; a PVC or SVC defined the communications along a path, so it's easy to define the parameters to control traffic characteristics. I'm not that familiar with IP QOS; is there an equivalent functionality that would apply? If so, could the problem be solved by making the attack "unattractive" (nondisruptive)?
Can someone comment on why these fuel cells use methanol instead of isopropyl alcohol? Is it a matter of efficiency, or is the reaction not acceptable for some reason (e.g., byproducts, manufacturing process)?
Isopropyl is much more easily available (most hotel gift shops even carry it, not to mention every grocery and drug store). If the fuel cells were consumer refillable with isopropyl, they would be accepted by the market much more easily.
"In a demonstration for Reuters, a prototype -- roughly the size of a dishwasher -- was run for around 10 minutes using four 12-volt car batteries as an initial power source. Emitting a steady motorized hum, the machine powered three 100-watt light bulbs for the duration."
It sounds like the box contained a bunch more batteries, and a DC-to-AC inverter (the "hum"). If the box contains 5 12V batteries, the 4 external batteries would be charged (at least initially). The combination of 9 12VDC batteries, could keep 3 100 watt bulbs going for a long time (probably at least a day, enough to wear out any news reporter).
It doesn't sound like much of a trick from the description.
Feel free to copy/paste/send:
---
Regarding the Microsoft settlement, I don't believe that the current proposal provides adequate reparations to those injured by Microsoft's anti-competitive behavior. Hundred, even thousands, of small companies have ceased to exist over the decades because of Microsoft's business practices.
Similar to the settlement against AT&T, Microsoft should become a government regulated Monopoly, until its market share drops to an acceptable level (40%, for example, assuming one of it's competitors is now also at 40%). This must be true for all Microsoft product lines, before regulation is lifted.
Even after being found guilty of being an illegal monopoly, Microsoft's behavior has not changed. Regulation of their behavior, with the threat of severe criminal penalties for failure to comply, is the only remedy that I can see will curtail them. The market must be able to return to a state of competition.
Imagine the damage to the United States if Microsoft were to fail, as Enron failed. The risks of a monopoly are greater than merely the loss of competition.
Thank you for your time.
If you're comparing Mhz, then you're right, it doesn't look very impressive. That's why you need to compare work performed per unit time.
:-)
Mainframe benchmarks are not performed like PC benchmarks; the idea it to completely remove (as much as possible) any constraint on the performance of the CPU (i.e., operate the CPU unconstrained). The measurement is solely the perform of the CPUs, and not the I/O subsystem.
The problem is that microcoded instructions operate like very complex instructions. It's somewhat like comparing CISC to RISC. In this case, the PC CPU (say, a P4) you are using as a base is actually the RISC CPU in the comparison.
MHz became very meaningless along time ago in the mainframe world. For a while, they had gone to adjusted MIPS (millions of instructions per second), based on an adjusted comparative value to an ancient mainframe. That fell apart about 15 years ago, and TPS (transactions per second; work per unit time) became the comparative measurement for judging the performance of a mainframe CPU. It's probably changed; I've been out of the field for 6+ years now.
If you wanted to compare a PC CPU like the P4 to a mainframe CPU, you would need to establish an "equal workload unit", then measure the number of workload units completed in a given interval by each processing complex operating unconstrained.
We spent 2 days just establishing and validating a baseline at the IBM Washington Systems complex for a benchmark about 10 years ago. It's not quite as simple as comparing the Mhz numbers.
Even on home cable, it's not feasible. I had done this when I had gotten 1-2 scans a day. I never received a response to the report. A few trojans ago, the scan rate picked up (now over a dozen a day). It's gotten to the point where I just turn the monitoring for scans off (still watch for unauthorized access). This is just me at my home PC; it would be a full time job to keep up with this. It's just not feasible.
We need an automated tool for collecting the scan data, and depositing it in a repository. The respository can perform the correlations to track these to the source nodes. Higher level (towards core) IPSs can take the lower level (towards edge) ISPs off net until the DoS is terminated.
If done properly, but still mostly manual operation, a DoS would last at most an hour. The problem is getting cooperation between companies and organizations that are business competitors. You need a third party independant organization (jointly or government funded) to manage the repository and request the service deactivation.
Of course, then the repository would itself become the target for attack...
Mainframes have the largest (fastest) CPUs except for the class of supercomputers.
Benchmarking a mainframe involves standalone use, which is rarely accessible except when performing a benchmark. It is analogous to single user operation on Linux. You cannot obtain a performance measurement in a multiuser environment. It's like trying to get Quake FPS numbers while there are 200 other users logged into your Linux machine, doing who knows what. You'd be lucky to get two measurements the same, and neither would be valid.
The mainframe instruction set also contains incredibly complex instructions, which are microcoded. The SIE (start interpretive execution) instruction is an example. This single instruction handles the execution of a virtual machine in it's own unique environment (this is what handles running multiple Linux virtual machines on the same mainframe). This makes the concept of "MIPS" and "MHz" completely meaningless.
As a result, benchmarks concentrate on throughput: transactions per seconds or workload executions per unit time.
Someone else mentioned the I/O system on mainframes. The architecture is somewhat analogous to using a PostScript printer, from the 22,000 mile view. The CPU writes a program (channel program; a collection of CCWs -- channel command words). It transfers that to one of the, possibly multiple, dedicated I/O CPUs called IOPs (I/O Processors) in the mainframe with a single instruction. These IOPs in turn transfer operations to the dozens to hundreds of device controllers (over 1-16 of the possibly hundreds of parallel ~OC3 speed I/O channels), which are small I/O computers outside the mainframe. The controllers in turn talk to the actual devices (up to 32 per controller). There can be (and frequently are) thousands of devices attached to the mainframe at once (disk drives, communications controllers, printers, tape drives, etc.).
All I/O operations are asynchronous and essentially DMA. Much of the I/O error recovery is performed by the IOP and controllers without intervention from the main CPUs. In addition, misbehaving devices can be identified and recovered independantly, or isolated from the system. There's no such thing (barring a now very rare bug) as a malfunctioning device causing a system failure.
Memory bandwidth is very high as has been mentioned, but it's also multiported, multiplying the bandwidth. That is, memory is read and written to concurrently by multiple CPUs and IOPs.
The ideal mainframe environment is one in which the CPUs are running at about 80-85% average CPU utilization, 7x24x365. Enough headroom for peaks, but well utilized. The elimination of all bottlenecks in the processing complex is a required requisite to achieve this state. It's the ultimate hardware hacker/overclockers dream machine.
Exactly. Classical "users" don't upgrade their kernels from source. Those that do, should know that the MD5SUM is available. You can even make the MD5 verification part of the build process, it that is a concern:
# make
*** MD5UM file not found. Copy MD5 file "xyz"
from http://www.trustedsource.com to the kernel directory before performing a make.
This might not be a bad idea anyway, to keep people from becoming complacent.
It may be inefficient in space; but my cable can transfer at 600KBs (that K-Bytes, not bits) per second, because I am going to a "local" server in my cable company. It doesn't matter if a 22MB kernel becomes 60MB, I can still get it in under 2 minutes. And there are a lot of Usenet servers.
Asking for a big chunk of bandwidth and centralized management is the problem. It's expensive. Instead:
- Use the existing file sharing networks
- Netnews (I can get the file faster from my ISP's news server than anywhere else), and software like pan makes getting all the pieces trivial.
- Are there any open file sharing projects that we could use? Something that limited to a single download per user wouldn't be onerous. There are lots of cable/DSL linux users.
"Add a soupçon(?) of artificial intelligence and the suit could save its wearer if he is wounded. "You could send a command to take this guy home," says Stephen Jacobsen, CEO of Sarcos."
Then so could the enemy, I would guess...
Uhh... first of all, my HS Prism is 72MB with the Memplug (with 64MB SmartMedia) and PiDirect. Yes, it works just like regular memory. It's great for keepin a couple of dozen full-length Linux manuals handy. Not to mention a dozen full-length novels, in case I get bored somewhere. Throw in a few dozen large databases for reference.
I don't know why people think that there is a lack of color applications; current versions all take advantage of the color display: iSilo, JFile, FireViewer, Mapopolis, HsPhoto Album, Planetarium, and loads of games (I've got 15 loaded right now).
"a crystal of yttrium silicate containing a few atoms of the element praseodymium"
They need a catchy marketing name... Something like DyLithium Crystals.
DivX;) and MPEG4 support would be much more useful. As long as they have that, who would care if they also supported MS formats? My MP3 player supports Windows Media as well; that doesn't mean any of it will ever find its way into my equipment.
More importantly, do any DVD manufacturers plan to have flashable/upgradable machines (stick in a CD-R with a file called FLASHUPG.PAT and autoupgrade)? How about an "open" DVD player? You can alway have a ROM version of the software to fall back on for user errors...
Media formats are evolving too fast for the existing equipment to keep up; it locks consumers and media manufacturers into old technology.
In no particular order... Chromium, Tux Racer, GLJewel, KShisen, PySol.
Children do what children do; push buttons to establish limits. That's their job. Punish the managers and complacent sysadmins at the companies impacted, that allowed themselves to get a year behind on maintenance. There will always be children. We don't always have to be cheap/lazy about security. At least not if we're going to bitch and moan about stuff that's completely preventable.
If our government were properly e-enabled, including electronic instant runoff voting, then active participation would be much greater. Just take a look at the response the ./ polls get :-)
...video conferencing on the desktop, which has been available for years. Why does anyone think that they will want it in their cell phone?
...the place to be, especially if you live near a school, and know how to use AirSnort :-)
...if the bad guys have a BlueTooth keyboard and/or mouse, since it's broadcasting every key stroke and mouse movement. A high gain directional antenna and amplifier will let them "target" a home miles away.
Chocolate covered expresso beans, Jelly Bellys and some chocolate licorice.
Oh, and as long as you're going out, a Toshiba 3000-S304 (with 512MB) with RedHat 7.2, nicely tweaked. No need to be greedy.