What about something like OTR?
on
VoIP Security
·
· Score: 3, Interesting
Can't something like OTR (Off The Record messaging - http://www.cypherpunks.ca/otr/) be applied to SIP or IAX conversations? I know it was designed for slow, IM-type packet traffic, but the crypto is there. It can't be that hard:)
Your problem is that you contracted this out to a company that grew up during the dot com haze and they gave you a dot com CMS. Now they're more than happy to manage and maintain the beast.
If you weren't using proprietary Java APIs (from BEA, ATG, Broadvision, etc.) you could get the same system running on inexpensive Intel-based machines with Linux or FreeBSD, Apache, JBOSS or JonAS (I can't believe nobody mentioned it yet) or even straight Tomcat with a Postgres DB on the back-end. All free/open source software.
Then refactor/re-architect the system. There have been plenty of comments and suggestions about that. No need to move to PHP unless you prefer maintaining pages of script language over a good MVC development approach.
I recently configured a JBoss server and I was unpleasantly suprised by the selfish attitude of the JBoss development community.
I've been using products from the Apache group for many years now, and I have never encountered a problem that wasn't addressed (one way or another) in mailing lists, newsgroups, etc.
When I encountered a problem with JBoss, I immediately went through the same channels but found nothing. I then noticed that they have a forum on their website and quickly found postings from other people with the same problem. The answer from the JBoss "experts": Buy the book! (take a look for yourself here and here or simply search for "buy the book" in their forums!).
Don't get me wrong. I have nothing against selling documentation as a business model, nor am I against the certification scheme. But what kind of an answer is that??
They may have a cool product, but with that attitude, I don't think it will be long before some people throw together a JBoss Documentation Project and bypass them alltogether. It is open source after all:)
That's more in line with what I thought when I posted. Not that it would make a great scanner, but that if it becomes ubiquitous, new and cool applications could be devised for barcodes at the consumer level. Getting people to install yet another peripheral just to scan barcodes doesn't work, as proven by the CueCat. But if the functionality is there, it will be used!
Regarding #2, I didn't think about it as a replacement for a good scanner. But it could be a way to get barcode scanning to "the people". Instead of asking people to install a crappy piece of hardware that drains miliamps most of the time, get them to install crappy software:)
If it ever got massified, barcodes could have a renewed life for consumers.
I agree. Getting the raw data would probably be the most likely scenario. I wonder what kind of bandwidth we're talking about. Integrating the decoding function done by the hardware in the mouse driver itself will probably be too resource consuming. But if it's possible, the driver would have to accomplish both tasks: decode movement AND barcode data (if present).
I does look sweet. I've seen this approach and, although very cool, I think optical mice have a much higher potential of becoming ubiquitous peripherals than webcams (even though you can get a cam for as little as $20-$30).
Are these "jumps" fairly consistent? I am not able to reproduce (or perceive) this behavior with my Microsoft Intellimouse (on a black & white pattern).
After reading a couple of other posts, I think the first challenge is to extract the actual "light" data from the mouse. If all we're getting is decoded mouse movements the graceful "all software" solution may not be possible.
Thanks for the explanation in the first scentence. However, I don't see why you need to insult.
You may know about peripheral hardware but based on your "analogy" with OO programming comment, it is clear that you have a lot to learn in that field. I promise that if you ever post a question about OO, I'll give you an honest and mature answer, and I won't call you a moron for asking (even if you are one).
Omnicontrol of every unit/viewing/hearing of copyrighted material is simply not possible without total hardware control (and halting technical innovation forever).
How long can the media and entertainment industry push this before the market forces the new realities of the medium? Once a "title" is realeased, it is already "out there". Forever accessible and reproducible with minimum effort. No matter what encryption/watermarking scheme they come up with, somebody somewhere will always bypass it.
Copyright infringement will happen no matter what. Companies and people will simply have to adapt to the idea that there will be new ways of making money with entertainment.
It is not going to be just a new way of selling CDs online. It won't be charging for download or by viewing. It will simply be different, new. Media companies should spend more time shaping their futures by helping define that "new" than trying to keep their unsustainable business model alive.
Unfortunately, the only way to get this through to current senior management in this industry is...actually, there is no way. We're just gonna have to wait until today's 12 to 18 year olds are running these companies and in a position to understand the new market.
Slashdot Mirror
Can't something like OTR (Off The Record messaging - http://www.cypherpunks.ca/otr/) be applied to SIP or IAX conversations? I know it was designed for slow, IM-type packet traffic, but the crypto is there. It can't be that hard :)
Your problem is that you contracted this out to a company that grew up during the dot com haze and they gave you a dot com CMS. Now they're more than happy to manage and maintain the beast.
If you weren't using proprietary Java APIs (from BEA, ATG, Broadvision, etc.) you could get the same system running on inexpensive Intel-based machines with Linux or FreeBSD, Apache, JBOSS or JonAS (I can't believe nobody mentioned it yet) or even straight Tomcat with a Postgres DB on the back-end. All free/open source software.
Then refactor/re-architect the system. There have been plenty of comments and suggestions about that. No need to move to PHP unless you prefer maintaining pages of script language over a good MVC development approach.
Did this scentence strike anybody else as odd?
Though Toynbee and Kubrick were both brilliant British visionaries...
Hmmm. Talk about thorough journalism...Stanley Kubrick was born in The Bronx, New York City.
I've been using products from the Apache group for many years now, and I have never encountered a problem that wasn't addressed (one way or another) in mailing lists, newsgroups, etc.
When I encountered a problem with JBoss, I immediately went through the same channels but found nothing. I then noticed that they have a forum on their website and quickly found postings from other people with the same problem. The answer from the JBoss "experts": Buy the book! (take a look for yourself here and here or simply search for "buy the book" in their forums!).
Don't get me wrong. I have nothing against selling documentation as a business model, nor am I against the certification scheme. But what kind of an answer is that??
They may have a cool product, but with that attitude, I don't think it will be long before some people throw together a JBoss Documentation Project and bypass them alltogether. It is open source after all :)
That's more in line with what I thought when I posted. Not that it would make a great scanner, but that if it becomes ubiquitous, new and cool applications could be devised for barcodes at the consumer level. Getting people to install yet another peripheral just to scan barcodes doesn't work, as proven by the CueCat. But if the functionality is there, it will be used!
If it ever got massified, barcodes could have a renewed life for consumers.
I agree. Getting the raw data would probably be the most likely scenario. I wonder what kind of bandwidth we're talking about. Integrating the decoding function done by the hardware in the mouse driver itself will probably be too resource consuming. But if it's possible, the driver would have to accomplish both tasks: decode movement AND barcode data (if present).
I does look sweet. I've seen this approach and, although very cool, I think optical mice have a much higher potential of becoming ubiquitous peripherals than webcams (even though you can get a cam for as little as $20-$30).
After reading a couple of other posts, I think the first challenge is to extract the actual "light" data from the mouse. If all we're getting is decoded mouse movements the graceful "all software" solution may not be possible.
You may know about peripheral hardware but based on your "analogy" with OO programming comment, it is clear that you have a lot to learn in that field. I promise that if you ever post a question about OO, I'll give you an honest and mature answer, and I won't call you a moron for asking (even if you are one).
...find a new business model!
Omnicontrol of every unit/viewing/hearing of copyrighted material is simply not possible without total hardware control (and halting technical innovation forever).
How long can the media and entertainment industry push this before the market forces the new realities of the medium? Once a "title" is realeased, it is already "out there". Forever accessible and reproducible with minimum effort. No matter what encryption/watermarking scheme they come up with, somebody somewhere will always bypass it.
Copyright infringement will happen no matter what. Companies and people will simply have to adapt to the idea that there will be new ways of making money with entertainment.
It is not going to be just a new way of selling CDs online. It won't be charging for download or by viewing. It will simply be different, new. Media companies should spend more time shaping their futures by helping define that "new" than trying to keep their unsustainable business model alive.
Unfortunately, the only way to get this through to current senior management in this industry is...actually, there is no way. We're just gonna have to wait until today's 12 to 18 year olds are running these companies and in a position to understand the new market.