maybe i should clarify -- SNMP for a wide range of devices over a less-than-perfect network can be a nightmare. a lot of heavy iron (routers, PIXs, etc) support SNMP, but a lot only support v2 and v1 -- UDP.
when a piece of metal needs to be monitored from something that further than a piece or two of cat5 away, being forced into UDP can make SNMP borderline useless. did the packet drop, or is the network down? hmm.. ill use SNMP to see if its the network. hmmm, negative. did the packet drop, or is... rinse, repeat.
add the lack of error protection, and SNMP can be very very frustrating. and sure, UDP will make it *most* of the time, but there are a lot of applications for SNMP where most just isnt good enough.
SNMPv3 does largely mitigate the problems by allowing TCP instead of just UDP. but, the reason for not replacing SNMP also holds SNMP back: a lot of the massive instaled base is in big iron, that does not support SNMPv3 over TCP.
basically, the more ive worked with SNMP, the more ive realized that the "S" is the key letter. it is fantastic for some quick chores ona local reliable network, but just plain doesn't scale. there is a vast array of management and monitoring problems that just arent simple enough for SNMP to handle well.
Microsoft has had a "implementation" (term used loosely) of WBEM in windows since as far back as at least Windows 2000 -- except it defined its own little corner of the MIB tree and didnt store anything in the actualy useful standard MIBs.
Of course, WBEM didnt have any marketing to go with it, so it died.
then again, at least its another shot to put SNMP in the grave where it belongs. especially before version 3, SNMP is a brutal and unreliable hack. im sure somebody will disagree quickly, but i can promise you that person never used SNMP for any major network management. *shiver*
Re:More Democratic Market
on
The Long Tail
·
· Score: 1
bobby derren maybe. but, you can still play sinatra on a jukebox. just about any jukebox.
somehow i doubt youll hear britney in a bar in 40 years.
plus, if you want an actual musical answer, sinatra had a talent for altering phrasing of the lyrics behind, slower, and faster than the accompaniment through songs. while it had been sorta done before, he was the first person with the feeling for it that actually made it sound good, and it was what separated him from the other crooners. thats why there were a million deam martins and only one sinatra.
if you want to go down this road, you would would have a much harder time separating the beatles from a modern day boy band, but somehow i doubt you would get away with impeaching the beatles impact on music.
this interview contribures nothing. almost all of his comments about subversion seem to be of the "you suck!" variety; plenty of emotion, not much fact. on the points he did make:
Subversion requires a fairly heavyweight server
i run a subversion repository on a FreeBSD system with a Duron 600 and 128Mb of memory, and the upstream link is only 128kbps dsl. subversion runs as smooth as silk, locally and remotely. i do not consider this to be a heavyweight server.
The implementation is too complicated, the use of BDB as the primary back end creates admin hassles... managing database log files and backups
somewhat true. i dont like the fact that subversion is currently tightly bound to BDB and Apache, but this is purely behind the scenes -- subversion's implementation can (and i imagine will) be evolved to support many backends, and issues with BDB are just issues with BDB. i dont think its fair to expect subversion to be fully open and support all sorts of databases and file systems for its backend at 1.06. furthermore, evolution of the implementation can be done so that old repositories still work fine with a new version, the new version has the option to use a dfferent backend, and most importantly, there will be absolutely no difference for user whatsoever.
having to run a recovery process or worse on the server whenever it fail
recovering a corrupted database of filesystem is never fun. nobody looks forward to running fsck. however, Lord makes this sound like a common operation for whenever something fails -- clearly, he has never typed the words svn help cleanup. when user operations go bad, it doesnt corrupt the repository, and recovery isnt necessary. any problems created by an interrupted operation affect only the working copy, and can be fixed with a simple svn cleanup.
the poor merging support
Lord references the poor merging support a few times, but fails to actually detail a complaint.
branching as a copy is just a clean intuitive manner to visualize a new branch off of the current line, and one that works with his precious named identifiers instead of version numbers as well. the merging is a little different than cvs, but is as good at worst. if Lord can go off on "Arch is great (you just have to learn all about it and configure your environment in just the right way)", i would think he would leave some leeway for subversion requiring a user to have at least a general birds eye view of its operation.
overall, this interview is like a political campaign that only attacks. i do not see any arguments in the text of "arch is better in this area because...", i only see "XXX is bad for the other guys." i've always taken the same view of these campaigns: if he had substance to support his product, he would have given it to us.
and in finale, he uses the final paragraph to make excuses for arch having most of the same shortcomings he lists for other revision control systems.
in all honesty, i am not familiar with arch. if arch does things better than subversion, i would love to hear it; and i am not claiming here that subversion is better. i can't, since i dont know arch. Lord would have been wise to use this interview as a forum to tell us about arch, and tell us why its good, but he didnt, and he has unfortunately turn my view on arch from neutral to maybe a little negative by virtue of jerkitude.
i take one overall feeling from this interview, due to its lack of content and vitriolic but often uninformed attacks. Tom Lord, who are you trying to fool?
didnt this get shelved last summer after a brutal panning by critics? i thought i remembered this movie being a laughingstock.
i have a friend who likes possibly the worst movies ever made. he was thrilled when too fast too furious got on HBO or starz or whatever it was on... and even he thinks this movie looks like cheesy garbage.
Hydrogen as an enegry storage medium is the key. using "free" energy -- ie, solar, wind, hydroelectric, geothermal -- may not store as much energy as can be put directly onto an electric wire, but does store energy as or more efficiently than other existing technologies, and is stable, portable, and clean.
regardless of efficiency, using natural "free" energy sources results in an unlimited energy production and storage medium.
any device, convention, or algorithm for any secure exchange falls into one of two categories.
the first is algorithmic. this is where NP-complete comes in, as well as NP-hard. first off, no, there are not approximately linear heuristic solutions to np-complete problems. you may feel smart tossing that out like its a fact, but i invite you to give me one example of a near linear (hell, near polynomial) np-complete problem heuristic that holds for a large probelm space. ill make you a bet: if you can, you have already won both a nobel prize and a fields medal. you are straightforwardly proving that you are out of your element discussing P vs NP.
second, there is the topic of a direct physical security. yes, quantum key exchange does obviate algorithmic security. however, quantum key exchange requires a physical implementation, and the improtant parts of security and cryptography in our time are based on security over an insecure link. if we had the luxury of a lower bandwidth, completely secure link for pad exchange, none of this would matter. however, pad exchange is a reality; and has been ever since caesar was tattooing one time pads on his messengers heads. why? because that was the closest he could get to a secure link.
while physically secure links obviate the need for algorithmic security, physically secure links are not widely available, and the interesting problem at hand is security over physically insecure links. thus, algorithmic security is what is important in the argument.
as for algorithmic security, the discovery of a P solution to an NP-complete problem would immediately destory current cryptography, period. even such a solution to an NP-hard would provide a clear path of research that would likely result in a NP-complete P solution in short time. such a solution would enable an efficient search of an entire solution space, and in case you dont understand that, a brute force password (or hash collision, certificate, any other damn thing) search could be implemented in time logarithmic to the size of the key.
you have officially left the signal and become part of the noise.
first off, data spread liberally over an address space does not ruin cache locality (unless you have a stupendously huge cache). learn how a cache works.
however, even if you were right about how a cache worked, youd be wrong in the argument. first off, malloc implementations usually scatter data just as much. though malloc can be implemented to stick all the data it can towards one end of the heap or the other, this results in an unacceptable level of heap fragmentation, and more wasted memory than you can shake a java-object-header-on-a-stick at.
also, most JVMs implement compacting garbage collectors. this means that most objects that have been around for a while end up very nicely packed into one contiguous area of memory -- something you wont ever get from C/C++, or any language implemented using malloc for allocation.
it shocks me that so many people who dont like java can only ever spout pseudo-facts about bad performance to bash on java; especially when there are so many actual barriers to using it in many situations. thank god you at least touched on lack of good, widespread VMs for portability.
and btw... its probably a bad idea to bash something for corporate 0wnedness in the same paragraph that you bash it for lacking market penetration. tsk, tsk.
on the other hand, careful what you wish for...
on
SIGGraph and Open Source
·
· Score: 4, Insightful
yes, writing the same thing over and over again is silly.
then again, when everything only has to be written once, its a lot harder to find someone to pay you to write anything. this is unfortunate for those of us who have no problem producing free software, but have slightly less enlightened landlords, loan officers, and grocers.
looks nice, but all its doing is killing monsters in dark corridors: yeah, describes both doom and doom 3.
fun: only describes doom.
do you think any of the millions who ran out to buy doom 3 because they loved doom so much would be complaining so loudly if it was really just a very pretty remake of doom?
and yes, it is very pretty -- the engine and the artwork are masterpieces. the sound is spectacular except for the weapon sounds; someone should have listen to someone fire a tank shell in UT2004 just once before releasing the game with a shotgun that sounds like your popping a paper bag. as artwork, its a stunning success.
i just didnt think, ot know anyone who thinks, it was any fun at all.
Yes, people could cram more and better functionality in there, and everyone is sure their idea will just make Java better; but every new version makes Java less and less portable. Adding the same functionality in a non-core library is every bit as effective, but doesn't add the additional requirement for a new version, and will avoid breaking and deprecating enormous existing bodies of code.
If you need new or better/differently implemented functionality, you are free to add it. If Java is unable to accomodate the addition outside the standard library, then the platform has failed.
Don't get me wrong -- I'm a fan of Java. But, if the core of a language needs to be constantly updated, its an unstable language, and bad for production development. I think Java can be stable, but it requires that the developers do just what they are. Keep the standard libraries standard, and not full of every shoehorned-in functionality they can think of. Its already bloated enough.
hey, what about AMD! AMD has their own architecture! AMD isnt intel!
oh wait... you mean someone already posted this? you say 50 people already posted this? gee, i just im just contributing noise to the signal. at least im sure nobody else will make the same mistake.
IBM releases the public key that corresponds to a private key stored on the card, the so called device key. The usual encode message with pub key, give to device, get decoded message back. Nothing will be able to perform this validation without the private key.
The only snag in this is if the hardware can be fooled with to extract the key, and though I really dont know anything about hacking hardare, I can't imagine that a high level security validation is given to a piece of hardware that easily gives up its secure information.
In other words, your xbox is not validated to FIPS-140 l4.
Slashdot Mirror
real geeks know that backjack is a sucker game.
i mean, its based on BSD.
(yes, thats sarcasm from a BSD user)
when a piece of metal needs to be monitored from something that further than a piece or two of cat5 away, being forced into UDP can make SNMP borderline useless. did the packet drop, or is the network down? hmm.. ill use SNMP to see if its the network. hmmm, negative. did the packet drop, or is ... rinse, repeat.
add the lack of error protection, and SNMP can be very very frustrating. and sure, UDP will make it *most* of the time, but there are a lot of applications for SNMP where most just isnt good enough.
SNMPv3 does largely mitigate the problems by allowing TCP instead of just UDP. but, the reason for not replacing SNMP also holds SNMP back: a lot of the massive instaled base is in big iron, that does not support SNMPv3 over TCP.
basically, the more ive worked with SNMP, the more ive realized that the "S" is the key letter. it is fantastic for some quick chores ona local reliable network, but just plain doesn't scale. there is a vast array of management and monitoring problems that just arent simple enough for SNMP to handle well.
Microsoft has had a "implementation" (term used loosely) of WBEM in windows since as far back as at least Windows 2000 -- except it defined its own little corner of the MIB tree and didnt store anything in the actualy useful standard MIBs.
Of course, WBEM didnt have any marketing to go with it, so it died.
then again, at least its another shot to put SNMP in the grave where it belongs. especially before version 3, SNMP is a brutal and unreliable hack. im sure somebody will disagree quickly, but i can promise you that person never used SNMP for any major network management. *shiver*
somehow i doubt youll hear britney in a bar in 40 years.
plus, if you want an actual musical answer, sinatra had a talent for altering phrasing of the lyrics behind, slower, and faster than the accompaniment through songs. while it had been sorta done before, he was the first person with the feeling for it that actually made it sound good, and it was what separated him from the other crooners. thats why there were a million deam martins and only one sinatra.
if you want to go down this road, you would would have a much harder time separating the beatles from a modern day boy band, but somehow i doubt you would get away with impeaching the beatles impact on music.
Subversion requires a fairly heavyweight server
i run a subversion repository on a FreeBSD system with a Duron 600 and 128Mb of memory, and the upstream link is only 128kbps dsl. subversion runs as smooth as silk, locally and remotely. i do not consider this to be a heavyweight server.
The implementation is too complicated, the use of BDB as the primary back end creates admin hassles... managing database log files and backups
somewhat true. i dont like the fact that subversion is currently tightly bound to BDB and Apache, but this is purely behind the scenes -- subversion's implementation can (and i imagine will) be evolved to support many backends, and issues with BDB are just issues with BDB. i dont think its fair to expect subversion to be fully open and support all sorts of databases and file systems for its backend at 1.06. furthermore, evolution of the implementation can be done so that old repositories still work fine with a new version, the new version has the option to use a dfferent backend, and most importantly, there will be absolutely no difference for user whatsoever.
having to run a recovery process or worse on the server whenever it fail
recovering a corrupted database of filesystem is never fun. nobody looks forward to running fsck. however, Lord makes this sound like a common operation for whenever something fails -- clearly, he has never typed the words svn help cleanup. when user operations go bad, it doesnt corrupt the repository, and recovery isnt necessary. any problems created by an interrupted operation affect only the working copy, and can be fixed with a simple svn cleanup.
the poor merging support
Lord references the poor merging support a few times, but fails to actually detail a complaint. branching as a copy is just a clean intuitive manner to visualize a new branch off of the current line, and one that works with his precious named identifiers instead of version numbers as well. the merging is a little different than cvs, but is as good at worst. if Lord can go off on "Arch is great (you just have to learn all about it and configure your environment in just the right way)", i would think he would leave some leeway for subversion requiring a user to have at least a general birds eye view of its operation.
overall, this interview is like a political campaign that only attacks. i do not see any arguments in the text of "arch is better in this area because...", i only see "XXX is bad for the other guys." i've always taken the same view of these campaigns: if he had substance to support his product, he would have given it to us.
and in finale, he uses the final paragraph to make excuses for arch having most of the same shortcomings he lists for other revision control systems.
in all honesty, i am not familiar with arch. if arch does things better than subversion, i would love to hear it; and i am not claiming here that subversion is better. i can't, since i dont know arch. Lord would have been wise to use this interview as a forum to tell us about arch, and tell us why its good, but he didnt, and he has unfortunately turn my view on arch from neutral to maybe a little negative by virtue of jerkitude.
i take one overall feeling from this interview, due to its lack of content and vitriolic but often uninformed attacks. Tom Lord, who are you trying to fool?
To me, a pretty computer ceases to be pretty when it sounds like a vacuum cleaner.
well, anyways, there goes the neighborhood.
proof by example: went through a few artists to see which i could find one missing. hit on weezer right away. no weezer.
...its google repackaged with some amazon ads thrown in and plenty of bloat. gee, where do i sign up?
step 1: insure.
step 2: hulk smash!
problem solved. fun, too.
if those are decent plots, i weep.
didnt this get shelved last summer after a brutal panning by critics? i thought i remembered this movie being a laughingstock.
i have a friend who likes possibly the worst movies ever made. he was thrilled when too fast too furious got on HBO or starz or whatever it was on... and even he thinks this movie looks like cheesy garbage.
and i also know everyone would love me if i said linux instead, but, well, screw off :)
or, you could switch to directv, and get the box for $40 and tivo service for $4 a month. at least here you could.
Hydrogen as an enegry storage medium is the key. using "free" energy -- ie, solar, wind, hydroelectric, geothermal -- may not store as much energy as can be put directly onto an electric wire, but does store energy as or more efficiently than other existing technologies, and is stable, portable, and clean. regardless of efficiency, using natural "free" energy sources results in an unlimited energy production and storage medium.
any device, convention, or algorithm for any secure exchange falls into one of two categories.
the first is algorithmic. this is where NP-complete comes in, as well as NP-hard. first off, no, there are not approximately linear heuristic solutions to np-complete problems. you may feel smart tossing that out like its a fact, but i invite you to give me one example of a near linear (hell, near polynomial) np-complete problem heuristic that holds for a large probelm space. ill make you a bet: if you can, you have already won both a nobel prize and a fields medal. you are straightforwardly proving that you are out of your element discussing P vs NP.
second, there is the topic of a direct physical security. yes, quantum key exchange does obviate algorithmic security. however, quantum key exchange requires a physical implementation, and the improtant parts of security and cryptography in our time are based on security over an insecure link. if we had the luxury of a lower bandwidth, completely secure link for pad exchange, none of this would matter. however, pad exchange is a reality; and has been ever since caesar was tattooing one time pads on his messengers heads. why? because that was the closest he could get to a secure link.
while physically secure links obviate the need for algorithmic security, physically secure links are not widely available, and the interesting problem at hand is security over physically insecure links. thus, algorithmic security is what is important in the argument.
as for algorithmic security, the discovery of a P solution to an NP-complete problem would immediately destory current cryptography, period. even such a solution to an NP-hard would provide a clear path of research that would likely result in a NP-complete P solution in short time. such a solution would enable an efficient search of an entire solution space, and in case you dont understand that, a brute force password (or hash collision, certificate, any other damn thing) search could be implemented in time logarithmic to the size of the key.
you have officially left the signal and become part of the noise.
He used an analogy about crystal cognac glasses to connect with the common man. I mean really, who have you met that doesn't have cognac glasses?
however, even if you were right about how a cache worked, youd be wrong in the argument. first off, malloc implementations usually scatter data just as much. though malloc can be implemented to stick all the data it can towards one end of the heap or the other, this results in an unacceptable level of heap fragmentation, and more wasted memory than you can shake a java-object-header-on-a-stick at.
also, most JVMs implement compacting garbage collectors. this means that most objects that have been around for a while end up very nicely packed into one contiguous area of memory -- something you wont ever get from C/C++, or any language implemented using malloc for allocation.
it shocks me that so many people who dont like java can only ever spout pseudo-facts about bad performance to bash on java; especially when there are so many actual barriers to using it in many situations. thank god you at least touched on lack of good, widespread VMs for portability.
and btw... its probably a bad idea to bash something for corporate 0wnedness in the same paragraph that you bash it for lacking market penetration. tsk, tsk.
then again, when everything only has to be written once, its a lot harder to find someone to pay you to write anything. this is unfortunate for those of us who have no problem producing free software, but have slightly less enlightened landlords, loan officers, and grocers.
fun: only describes doom.
do you think any of the millions who ran out to buy doom 3 because they loved doom so much would be complaining so loudly if it was really just a very pretty remake of doom?
and yes, it is very pretty -- the engine and the artwork are masterpieces. the sound is spectacular except for the weapon sounds; someone should have listen to someone fire a tank shell in UT2004 just once before releasing the game with a shotgun that sounds like your popping a paper bag. as artwork, its a stunning success.
i just didnt think, ot know anyone who thinks, it was any fun at all.
Yes, people could cram more and better functionality in there, and everyone is sure their idea will just make Java better; but every new version makes Java less and less portable. Adding the same functionality in a non-core library is every bit as effective, but doesn't add the additional requirement for a new version, and will avoid breaking and deprecating enormous existing bodies of code.
If you need new or better/differently implemented functionality, you are free to add it. If Java is unable to accomodate the addition outside the standard library, then the platform has failed.
Don't get me wrong -- I'm a fan of Java. But, if the core of a language needs to be constantly updated, its an unstable language, and bad for production development. I think Java can be stable, but it requires that the developers do just what they are. Keep the standard libraries standard, and not full of every shoehorned-in functionality they can think of. Its already bloated enough.
oh wait... you mean someone already posted this? you say 50 people already posted this? gee, i just im just contributing noise to the signal. at least im sure nobody else will make the same mistake.
Easy.
IBM releases the public key that corresponds to a private key stored on the card, the so called device key. The usual encode message with pub key, give to device, get decoded message back. Nothing will be able to perform this validation without the private key.
The only snag in this is if the hardware can be fooled with to extract the key, and though I really dont know anything about hacking hardare, I can't imagine that a high level security validation is given to a piece of hardware that easily gives up its secure information.
In other words, your xbox is not validated to FIPS-140 l4.
Heres a part where i rake in some money.
Ooh, heres another million... selling out, selling out, cashing in, nother million.
Money. Money, money.
Is anyone still watching this? suckers.
-George Lucas