LDAP uses ASN.1 as well, as it must. And while DAP was defined in the context of OSI protocols, it is not inseparably tied to them. Many companies have released good DAP over TCP implementations.
re: multi-master - like the SprintPCS guy said a few posts over - prone to failure and database corruption, utterly useless in an enterprise deployment.
re: plugin interface - OpenLDAP supports both the (incredibly inefficient) Netscape plugin interface and its own (incredibly fast) plugin architecture.
re: logging - "useful" is a subjective term. Since you don't explain what this means, it's difficult to comment further on it.
re: SNMP reporting - you're right, this is lacking in OpenLDAP, and for IT purchasers going down the checklist of "must haves" this can be a problem. The NetSNMP package is an easy solution here, especially with all of the information provided by OpenLDAP's cn=monitor. I know of several commercial OpenLDAP deployments where this was an issue at first, but integrating NetSNMP allowed the OpenLDAP deployment to proceed.
re: cn=config - This is implemented in OpenLDAP 2.3. And it doesn't require a server restart to make new plugin settings and other changes take effect, unlike Netscape/SunOne.
re: backups via LDAP-initiated commands - this topic actually came up on the openldap-devel mailing list recently. The conclusion was that it was a band-aid Netscape needed for their lame replication mechanism.
re: fast as hell - OpenLDAP 2.1 beats Netscape into the dirt. OpenLDAP 2.2 is even faster, and scales to large numbers of clients even better. If you still believe Netscape is faster than OpenLDAP, you haven't used a recent release of OpenLDAP.
Not since 1999-2000. The overall shape is still similar but the internal details have all been reimplemented by the OpenLDAP Project. Today OpenLDAP is miles ahead of Netscape in terms of performance, scalability, and stability.
OpenLDAP 2.0 is slow, snail's pace, frozen molasses slow. That's the release that RedHat has bundled for years, up to RH9 and even beyond. It's only in the past few months that anything from them (Fedora Core) has shipped anything newer.
OpenLDAP 2.1 is over Two Hundred Times faster than OpenLDAP 2.0 and already significantly faster than Netscape 5. OpenLDAP 2.2 is 30-50% faster than OpenLDAP 2.1 and leaves Netscape in the dust. OpenLDAP 2.3 is faster yet.
As I wrote in my journal http://yro.slashdot.org/~hyc/journal/85312
the real point here is that music has to belong to individual people, not big corporations. The RIAA isn't doing anybody any favors; most of the new artists that get signed by labels get screwed by contract terms that whittle all their sales earnings down to less than 1/100th of a percent of the gross, while the record companies take the rest. The only way to fix this situation is for artists to remain independent and market/distribute their music on their own. Anybody can set up a web site and put up copies of their music for sale/download. With the Internet today, you don't need the RIAA.
Your explanation makes no sense, you seem to have no idea what you're talking about. Sounds like what you're seeing is the difference between Solaris and Linux libc, particularly their stdio implementations. Again, that has nothing to do with the compiler. No compiler bug could cause this difference.
The fact is, when you have only one problem to solve, a single fast CPU is always better than an equivalent count of slower CPUs. One 1GHz CPU is better than 2 512MHz CPUs of the same design, for solving a single problem.
It's another fact that it's easiest for humans to analyze only one problem at a time. So the most straightforward way to handle any computing task it to crunch at it linearly from beginning to end.
Unfortunately, gains in raw CPU speed have always come slower than the demand for number-crunching power, which is why there have been so many parallel supercomputer designs over the past couple decades. And again unfortunately, the only way to get good performance out of those designs is by explicitly coding for parallel processing. And that's hard for humans.
The bottom line is that when you throw two 1GHz processors at a problem, your time to solution is not twice as fast as using one 1GHz processor. There are overhead costs associated with reallocating the problem and managing the increased number of processors. But, it *is* still faster than using one 1 GHz processor.
Scale the numbers up as appropriate.
Still, it was fun watching the blinking lights on our Connection Machine, a decade or so ago...
??? When an application calls fork() everything that happens next is up to the kernel. The definition of fork() is that the child gets an identical copy of everything. What does the compiler have to do with this?
I suppose a Centrino could get comfortably warm up there. A Prescott would probably run down their generators too fast, but I suppose they might have used that instead of other space heaters.
'way back, the reasonable explanation was "CPU companies sell processors marked at a slower speed because there are still systems out there that only work at the slower speed." The textbook example was the Motorola 68000; over time Motorola's chip fabrication got more and more sophisticated, as they moved to the 68020, 030, 040, and 060. The 68000 fab was benefiting from all these advancements at the same time; by the time the 68030 came out all of the new 68000s were actually 16 or 32 MHz parts but they still got sold as 8 MHz parts because that's where the 68000 had the most customers. People were regularly overclocking these newer chips to 48-50MHz and they ran perfectly fine. Motorola never sold them as 50MHz parts, I don't think they ever sold them as anything faster than 16MHz parts, but they were built on a fab line that was designed for 50MHz 68030s, and so it went.
No, it's not "unlimited" but it is typically "as many channels as you have CPUs" so there is no practical difference. The point is that it is not a bus structure at all; a bus is a single access channel that is shared by multiple accessors. On a crossbar switch, the channel is dedicated to the accessor when a target is selected.
As for HyperTransport - it is a generic interconnect standard, it can be used for any purpose. Your example is stupid, nobody would design a system with a bunch of CPUs connected to a single memory controller. Look at the Cray XD1 for an example of a multiprocessor system that does use HyperTransport, intelligently.
re: unlimited simultaneous memory access - it's called a crossbar switch, and a lot of parallel supercomputers use them. They are fairly expensive, in real $$ and in terms of board space, etc...
The HyperTransport that AMD uses is not a bad interconnect in the meantime, for people on smaller budgets...
Sorry for the redundant followup. Was actually just thinking about this earlier today. I think the milter should send a temporary failure code (4xx) instead of a permanent failure code (5xx) because then
1) if the filter rejected legitimate mail, you have a grace period in which to install an exception for the sender, and it will automatically be redelivered later (You obviously have to inspect the logs frequently, to detect this.)
2) if mail is really spam, it still won't get delivered, as most bulk mailers only try once anyway. And if the spam is coming via a regular sendmail/postfix queue, then it will just backup in the sender's queue.
The article claimed 120W per square inch, which I'm going to assume is a typo, since they're only claiming 12% conversion efficiency. Otherwise, something truly magical is happening.;)
State-of-the-art in amorphous silicon 15 years ago was 4 watts per square foot. If their 14x10 foot panel is only putting out 120W they've got a long way to go.
That argument wouldn't hold though. There are multiple types of copyright, including copyright on individual creative works, and compilation copyrights which are rights to any assembly of material. You can collect a bunch of public domain items into a single volume and get a compilation copyright on the collection. That would forbid anyone else from copying *the collection* verbatim and distributing it. But since the individual elements are public domain, anyone can copy them at will.
So for someone to claim "the position of this silence on my album is artistically significant" they're going to lose. Yes, the album as a whole is protected by a compilation copyright, but an individual element of silence could ony be construed as being in the public domain.
Read down where it talks about Carbon nanomaterials. Still a pipe dream, much like cold fusion.
I think my original point still stands - the density of hydrogen you can store doesn't compare well to the energy density of a LiIon battery. LiIon technology is something where every bit of incremental research pays off *today*, across a wide spectrum of consumer electronics. You may not solve the electric car recharge problem overnight (pun) but you'll be pushing a commercially viable and environmentally sustainable enterprise while you make advances down that road. Whereas, any advances that come from stuff like miracle carbon fiber nanotubes will take years to reach commercial viability, if it's even possible.
Fundamentally, I think the main point is we're running out of time. Our environment is going to hell, and the petroleum probably won't last much longer (and we will most likely be perpetually at war to secure what little remains). The car companies and oil companies are being disingenuous by getting behind a "plan" that will transition us to a hydrogen economy a "decade or two away" when even the most promising research can't possibly pay off that quickly, and they've had cars like the GM EV1 that were already reasonably good cars, cars that would be totally acceptable if they used LiIon and could be recharged on a home's 220V AC power instead of just at a handful of special-purpose recharging stations. (Like the ACPropulsion Tzero.)
re: solar panels on SUVs - you can probably get at most a 100 watts or so from the surface area of a vehicle. Less than 1/7th of one horsepower. Not worth the cost.
Japan is geographically so small they have precious little of anything. That means they are entirely dependent on foreign resources for any of their industries to survive. As such, you can't really say they're totally free to build and market whatever they want. One of the realities of living in a global economy - everybody is affected by everybody else.
re: hydrocarbons - again, they're "cheap" today only because billions (trillions?) have already been spent on their development and infrastructure over the course of a century or more. (Think about how long internal combustion engines have been around!) So now we have technologies that are *beginning* to show promise after only 10 or 20 years; surely if they had as much time/experience under their belt we could do better. (Otherwise what is the point of doing research at all?)
No, a fuel cell is just a battery with external electrolyte that is consumed in the reaction. There is no "extracting the energy directly from the hydrogen." The hydrogen still goes thru redox reactions to produce electricity. Or, it is oxidized to produce heat and mechanical energy, but that's not what current vehicle programs are targeting.
You're probably right that the amount of hydrogen is lower in a NiMH battery, but the difference isn't so great.
http://www.cobasys.com/pdf/tutorial/inside_nimh_ ba ttery_technology.pdf
(See page 8) A NiMH battery typically contains 1-2% hydrogen by weight, vs about 7% maximum achievable. So, the most efficient available MH only provides about 3 times denser H2 content than an off-the-shelf NiMH battery.
Recharge times may be a pain, but simply getting Hydrogen in and out of the MH tank is no picnic either.
http://sti.srs.gov/fulltext/ms2003172/ms2003172. pd f
I suppose 1 hour is better than 6 hours but that's still fairly impractical, leading to solutions that involve exchanging depleted tanks for full ones at a fillup station. I personally would be pretty nervous about accepting a refilled tank that had been used by god-knows-who before me. Especially in this age of terrorist paranoia, the whole idea is ludicrous.
http://www.apfct.com/hydrogen_inf.htm
LiIon battery cost is just about mass market commercialization. As demand goes up, and production volume rises to meet the demand, prices will come down, just as they have for Nickel-based batteries. And if things like Altair's improved battery electrodes pan out, then we'll be able to recharge LiIon batteries in minutes instead of hours.
What's really interesting is they claim that the density of Hydrogen in a metal hydride is actually denser than in pure liquid H2. The stupid thing is that the energy density *is* equivalent to a NiMH battery. Why is all of this research money being funneled into Hydrogen-powered systems, when we already have LiIon that has even greater energy density than NiMH? The whole Hydrogen-fuel-cell caper is just another scam perpetrated by an oil industry that doesn't want to let go of its stranglehold until every last drop of oil under the middle-eastern desert has been sold at a ridiculous profit.
I think you give the LDAP "designers" far more credit than is due. They had no idea what they were doing, as anyone with network protocol design experience can see. And as LDAP use continues to grow it becomes more and more obvious where all the shortcuts they took by dropping X.500 features have come back to bite everyone.
Yes. My badDNS milter for sendmail does exactly this. Handling the spam after your mail server has already accepted it is too late, my milter sends a reject code after receiving the envelope headers.
It also does a 20 second delay before sending the reject code, to slow down the spammer from moving on to their next target.
Read about it and download the source code on my web page. http://highlandsun.com/hyc/
I've been using it for over a year and my spam-to-mail ratio dropped from 95% spam to 5% spam.
By default Tripwire comes with a whole slew of hash algorithms, and back in the day when I was deploying it on our packaged servers, we alway enabled all of them. The cost in computation time is really trivial.
Of course, the other obvious conclusion from this is that we might as well design one new hash algorithm that generates 512, 1024, or 2048 bit hashes, rather than running a handful of separate hash algorithms that each produce 128 bit hashes.
Slashdot Mirror
LDAP uses ASN.1 as well, as it must. And while DAP was defined in the context of OSI protocols, it is not inseparably tied to them. Many companies have released good DAP over TCP implementations.
re: multi-master - like the SprintPCS guy said a few posts over - prone to failure and database corruption, utterly useless in an enterprise deployment.
re: plugin interface - OpenLDAP supports both the (incredibly inefficient) Netscape plugin interface and its own (incredibly fast) plugin architecture.
re: logging - "useful" is a subjective term. Since you don't explain what this means, it's difficult to comment further on it.
re: SNMP reporting - you're right, this is lacking in OpenLDAP, and for IT purchasers going down the checklist of "must haves" this can be a problem. The NetSNMP package is an easy solution here, especially with all of the information provided by OpenLDAP's cn=monitor. I know of several commercial OpenLDAP deployments where this was an issue at first, but integrating NetSNMP allowed the OpenLDAP deployment to proceed.
re: cn=config - This is implemented in OpenLDAP 2.3. And it doesn't require a server restart to make new plugin settings and other changes take effect, unlike Netscape/SunOne.
re: backups via LDAP-initiated commands - this topic actually came up on the openldap-devel mailing list recently. The conclusion was that it was a band-aid Netscape needed for their lame replication mechanism.
re: fast as hell - OpenLDAP 2.1 beats Netscape into the dirt. OpenLDAP 2.2 is even faster, and scales to large numbers of clients even better. If you still believe Netscape is faster than OpenLDAP, you haven't used a recent release of OpenLDAP.
Not since 1999-2000. The overall shape is still similar but the internal details have all been reimplemented by the OpenLDAP Project. Today OpenLDAP is miles ahead of Netscape in terms of performance, scalability, and stability.
a p/history/index.html
See for yourself:
http://www.stanford.edu/services/directory/openld
OpenLDAP 2.0 is slow, snail's pace, frozen molasses slow. That's the release that RedHat has bundled for years, up to RH9 and even beyond. It's only in the past few months that anything from them (Fedora Core) has shipped anything newer.
OpenLDAP 2.1 is over Two Hundred Times faster than OpenLDAP 2.0 and already significantly faster than Netscape 5. OpenLDAP 2.2 is 30-50% faster than OpenLDAP 2.1 and leaves Netscape in the dust. OpenLDAP 2.3 is faster yet.
As I wrote in my journal http://yro.slashdot.org/~hyc/journal/85312
the real point here is that music has to belong to individual people, not big corporations. The RIAA isn't doing anybody any favors; most of the new artists that get signed by labels get screwed by contract terms that whittle all their sales earnings down to less than 1/100th of a percent of the gross, while the record companies take the rest. The only way to fix this situation is for artists to remain independent and market/distribute their music on their own. Anybody can set up a web site and put up copies of their music for sale/download. With the Internet today, you don't need the RIAA.
Your explanation makes no sense, you seem to have no idea what you're talking about. Sounds like what you're seeing is the difference between Solaris and Linux libc, particularly their stdio implementations. Again, that has nothing to do with the compiler. No compiler bug could cause this difference.
The fact is, when you have only one problem to solve, a single fast CPU is always better than an equivalent count of slower CPUs. One 1GHz CPU is better than 2 512MHz CPUs of the same design, for solving a single problem.
It's another fact that it's easiest for humans to analyze only one problem at a time. So the most straightforward way to handle any computing task it to crunch at it linearly from beginning to end.
Unfortunately, gains in raw CPU speed have always come slower than the demand for number-crunching power, which is why there have been so many parallel supercomputer designs over the past couple decades. And again unfortunately, the only way to get good performance out of those designs is by explicitly coding for parallel processing. And that's hard for humans.
The bottom line is that when you throw two 1GHz processors at a problem, your time to solution is not twice as fast as using one 1GHz processor. There are overhead costs associated with reallocating the problem and managing the increased number of processors. But, it *is* still faster than using one 1 GHz processor.
Scale the numbers up as appropriate.
Still, it was fun watching the blinking lights on our Connection Machine, a decade or so ago...
??? When an application calls fork() everything that happens next is up to the kernel. The definition of fork() is that the child gets an identical copy of everything. What does the compiler have to do with this?
I suppose a Centrino could get comfortably warm up there. A Prescott would probably run down their generators too fast, but I suppose they might have used that instead of other space heaters.
'way back, the reasonable explanation was "CPU companies sell processors marked at a slower speed because there are still systems out there that only work at the slower speed." The textbook example was the Motorola 68000; over time Motorola's chip fabrication got more and more sophisticated, as they moved to the 68020, 030, 040, and 060. The 68000 fab was benefiting from all these advancements at the same time; by the time the 68030 came out all of the new 68000s were actually 16 or 32 MHz parts but they still got sold as 8 MHz parts because that's where the 68000 had the most customers. People were regularly overclocking these newer chips to 48-50MHz and they ran perfectly fine. Motorola never sold them as 50MHz parts, I don't think they ever sold them as anything faster than 16MHz parts, but they were built on a fab line that was designed for 50MHz 68030s, and so it went.
No, it's not "unlimited" but it is typically "as many channels as you have CPUs" so there is no practical difference. The point is that it is not a bus structure at all; a bus is a single access channel that is shared by multiple accessors. On a crossbar switch, the channel is dedicated to the accessor when a target is selected.
As for HyperTransport - it is a generic interconnect standard, it can be used for any purpose. Your example is stupid, nobody would design a system with a bunch of CPUs connected to a single memory controller. Look at the Cray XD1 for an example of a multiprocessor system that does use HyperTransport, intelligently.
re: unlimited simultaneous memory access - it's called a crossbar switch, and a lot of parallel supercomputers use them. They are fairly expensive, in real $$ and in terms of board space, etc...
The HyperTransport that AMD uses is not a bad interconnect in the meantime, for people on smaller budgets...
Sorry for the redundant followup. Was actually just thinking about this earlier today. I think the milter should send a temporary failure code (4xx) instead of a permanent failure code (5xx) because then
1) if the filter rejected legitimate mail, you have a grace period in which to install an exception for the sender, and it will automatically be redelivered later (You obviously have to inspect the logs frequently, to detect this.)
2) if mail is really spam, it still won't get delivered, as most bulk mailers only try once anyway. And if the spam is coming via a regular sendmail/postfix queue, then it will just backup in the sender's queue.
Looks like I'll be updating my badDNS.c file...
See my sendmail milter, which does exactly this:
http://highlandsun.com/hyc/badDNS.html
It's helped my domain immensely.
The article claimed 120W per square inch, which I'm going to assume is a typo, since they're only claiming 12% conversion efficiency. Otherwise, something truly magical is happening. ;)
State-of-the-art in amorphous silicon 15 years ago was 4 watts per square foot. If their 14x10 foot panel is only putting out 120W they've got a long way to go.
That argument wouldn't hold though. There are multiple types of copyright, including copyright on individual creative works, and compilation copyrights which are rights to any assembly of material. You can collect a bunch of public domain items into a single volume and get a compilation copyright on the collection. That would forbid anyone else from copying *the collection* verbatim and distributing it. But since the individual elements are public domain, anyone can copy them at will.
So for someone to claim "the position of this silence on my album is artistically significant" they're going to lose. Yes, the album as a whole is protected by a compilation copyright, but an individual element of silence could ony be construed as being in the public domain.
7% maximum *for metal hydride*, period. Whether used as a battery or as a storage tank.
1 /p20.html
As for carbon fiber, this link sums it up pretty well:
http://www.tipmagazine.com/tip/INPHFA/vol-10/iss-
Read down where it talks about Carbon nanomaterials. Still a pipe dream, much like cold fusion.
I think my original point still stands - the density of hydrogen you can store doesn't compare well to the energy density of a LiIon battery. LiIon technology is something where every bit of incremental research pays off *today*, across a wide spectrum of consumer electronics. You may not solve the electric car recharge problem overnight (pun) but you'll be pushing a commercially viable and environmentally sustainable enterprise while you make advances down that road. Whereas, any advances that come from stuff like miracle carbon fiber nanotubes will take years to reach commercial viability, if it's even possible.
Fundamentally, I think the main point is we're running out of time. Our environment is going to hell, and the petroleum probably won't last much longer (and we will most likely be perpetually at war to secure what little remains). The car companies and oil companies are being disingenuous by getting behind a "plan" that will transition us to a hydrogen economy a "decade or two away" when even the most promising research can't possibly pay off that quickly, and they've had cars like the GM EV1 that were already reasonably good cars, cars that would be totally acceptable if they used LiIon and could be recharged on a home's 220V AC power instead of just at a handful of special-purpose recharging stations. (Like the ACPropulsion Tzero.)
Another decent summary of energy content in metal hydride vs gasoline...
1 /p20.html
http://www.tipmagazine.com/tip/INPHFA/vol-10/iss-
re: solar panels on SUVs - you can probably get at most a 100 watts or so from the surface area of a vehicle. Less than 1/7th of one horsepower. Not worth the cost.
Japan is geographically so small they have precious little of anything. That means they are entirely dependent on foreign resources for any of their industries to survive. As such, you can't really say they're totally free to build and market whatever they want. One of the realities of living in a global economy - everybody is affected by everybody else.
re: hydrocarbons - again, they're "cheap" today only because billions (trillions?) have already been spent on their development and infrastructure over the course of a century or more. (Think about how long internal combustion engines have been around!) So now we have technologies that are *beginning* to show promise after only 10 or 20 years; surely if they had as much time/experience under their belt we could do better. (Otherwise what is the point of doing research at all?)
No, a fuel cell is just a battery with external electrolyte that is consumed in the reaction. There is no "extracting the energy directly from the hydrogen." The hydrogen still goes thru redox reactions to produce electricity. Or, it is oxidized to produce heat and mechanical energy, but that's not what current vehicle programs are targeting.
_ ba ttery_technology.pdf
. pd f
2 23 2&tid=126/ DevProj_Bat teries.html
You're probably right that the amount of hydrogen is lower in a NiMH battery, but the difference isn't so great.
http://www.cobasys.com/pdf/tutorial/inside_nimh
(See page 8) A NiMH battery typically contains 1-2% hydrogen by weight, vs about 7% maximum achievable. So, the most efficient available MH only provides about 3 times denser H2 content than an off-the-shelf NiMH battery.
Recharge times may be a pain, but simply getting Hydrogen in and out of the MH tank is no picnic either.
http://sti.srs.gov/fulltext/ms2003172/ms2003172
I suppose 1 hour is better than 6 hours but that's still fairly impractical, leading to solutions that involve exchanging depleted tanks for full ones at a fillup station. I personally would be pretty nervous about accepting a refilled tank that had been used by god-knows-who before me. Especially in this age of terrorist paranoia, the whole idea is ludicrous.
http://www.apfct.com/hydrogen_inf.htm
LiIon battery cost is just about mass market commercialization. As demand goes up, and production volume rises to meet the demand, prices will come down, just as they have for Nickel-based batteries. And if things like Altair's improved battery electrodes pan out, then we'll be able to recharge LiIon batteries in minutes instead of hours.
http://slashdot.org/article.pl?sid=05/02/23/131
http://www.altairnano.com/main_content
What's really interesting is they claim that the density of Hydrogen in a metal hydride is actually denser than in pure liquid H2. The stupid thing is that the energy density *is* equivalent to a NiMH battery. Why is all of this research money being funneled into Hydrogen-powered systems, when we already have LiIon that has even greater energy density than NiMH? The whole Hydrogen-fuel-cell caper is just another scam perpetrated by an oil industry that doesn't want to let go of its stranglehold until every last drop of oil under the middle-eastern desert has been sold at a ridiculous profit.
I think you give the LDAP "designers" far more credit than is due. They had no idea what they were doing, as anyone with network protocol design experience can see. And as LDAP use continues to grow it becomes more and more obvious where all the shortcuts they took by dropping X.500 features have come back to bite everyone.
Yes. My badDNS milter for sendmail does exactly this. Handling the spam after your mail server has already accepted it is too late, my milter sends a reject code after receiving the envelope headers.
It also does a 20 second delay before sending the reject code, to slow down the spammer from moving on to their next target.
Read about it and download the source code on my web page.
http://highlandsun.com/hyc/
I've been using it for over a year and my spam-to-mail ratio dropped from 95% spam to 5% spam.
exponentially lower, you mean.
By default Tripwire comes with a whole slew of hash algorithms, and back in the day when I was deploying it on our packaged servers, we alway enabled all of them. The cost in computation time is really trivial.
Of course, the other obvious conclusion from this is that we might as well design one new hash algorithm that generates 512, 1024, or 2048 bit hashes, rather than running a handful of separate hash algorithms that each produce 128 bit hashes.
Of course they know that they're the primary instigator of the really annoying lawsuits anyway, so it's promise that doesn't cost 'em anything...