rtmpdump decodes the majority of RTMP streams in common use today. We know what the other (currently unsupported) options are doing in general; it just isn't worth the time right now to fully decode them until they become more of an inconvenience to more people. (Or in other words, until they become an inconvenience to the rtmpdump developers...)
rtmpe is fundamentally flawed, broken by design. Unlike SSL/TLS it is vulnerable to M-I-T-M attacks and always will be. Any new mechanisms Adobe layers on top of it can be trivially broken with the application of a few hours of CPU time. (In contrast, breaking TLS still requires thousands to millions of hours of CPU time.)
False. With RTMP you can only seek to key frames. If you seek to a timestamp that doesn't correspond to a keyframe, the server will pick the nearest keyframe using some undisclosed algorithm. (I.e., it is not specified anywhere whether it will pick the closest keyframe *before* or *after* the designated seek timestamp.)
Obviously you can't start playback from a non-keyframe, there isn't enough video data to construct a full frame.
I dunno, preserving your company's reputation and credibility ought to be big enough motivators already. The fact that Adobe code quality is still so shoddy indicates that regardless of motivation, they lack the *ability* to improve things.
Btw, for video streaming, you can just use things like get-flash-videos and rtmpdump, and never be exposed to any of that crappy Adobe code. Whether or not the base technology has any intrinsic merit, it's obvious that even today, before HTML5 is widely deployed, it's possible to implement this stuff without any of Adobe's implementation flaws.
Aside from the fact that this isn't news, it hasn't been a problem either. The patch to add the so-called "DRM" support to XBMC was made available within a few hours of the BBC change.
So what no one seems to have asked yet - when is someone going to take a fertilized human egg, and remove these viral sequences from the nucleus, and see how the embryo is affected?
Take the embryo after the first division, so you can have an identical twin as a control for the experiment...
But it took NASA to develop SAR and refine its use. I worked on the control software for SIR-C back in 1991-1994; all of the software that I wrote for that got re-used by RADARSAT and SRTM and probably other missions as well. (Haven't really kept tabs after I left.)
Aside from the other stupidity already being commented on, this is purely a case of bad design in the LED traffic signals. LEDs are ~4x more efficient than incandescents, but they're still far from perfect, and they still give off a *lot* of heat.
I've designed and built many lamps using high power/high brightness LEDs. Any time you design a high power LED lamp you have to heat-sink every single LED otherwise it will burn out. The obvious solution here is to run heatpipes from the sinks at the back of the LEDs to the lamp housing and/or front lens. There's no need to add a separate heater, every electronic device *is* a heater.
works great, covers a ton of sites already, and is easily extensible to add support for any new sites.
And yes, I agree with several of the posters above - I don't want to watch videos inside my browser; I don't want the distraction of multiple animated ads on the borders of the page etc...
this weekend large portions of Spain suffered extended blackouts as a number of the electric company's network routers were overwhelmed by an unexpected surge of traffic. This was apparently the result of an article about Spain's wind-based electrical program being published on slashdot.org, and the ensuing traffic overload from attempts to access the power generation graphs on the public site...
About the same time frame as those researchers and their discovery. Seems to me that this type of hacking has been going on all over, for a long time already.
And yes, I'd say it's criminally negligent to use any Windows OS on ATMs or anything else where security matters...
It's not so surprising though - it just means that the ants have been able to spread faster than their rate of evolution/mutation. Otherwise, they would have differentiated/speciated first. But because it's so easy for them to hitch rides on passing people, cars, boats, and airplanes, they've spread a lot faster than they would naturally have been able to.
The more interesting thing will be to observe over time and see how long it takes before their super-colony collapses or is torn apart by civil war. Of course that's not likely to occur until their paths of transport and communication are disrupted. If we don't destroy ourselves first, thus giving them a long time to continue to evolve in total connectedness, I guess things will get interesting for them down the road...
The other interesting point this raises is about language and communication in general - biologists frequently talk about animals communicating with each other via whatever their particular mechanisms may be, but they seem to assume that all the members of a species are homogeneous in their communication methods. That's a pretty naive assumption, given all the different vocal and non-vocal mechanisms various human tribes use to communicate. The interesting question here will be whether this super-colony is an example of genocide (the total annihilation of different/competing ant species) or assimilation...
I sometimes get to a point where I want to sketch out the problem on paper, but most of the time as I'm searching for a pen or pencil, and a decent sheet of paper, I've already figured out what it will look like in my head, and I quit searching.
Sorry, the eDirectory info is based on personal communication from a Novell engineer. (But it's worth noting that OpenLDAP's libraries are also better tuned than anyone else's, and Novell now ships OpenLDAP's libraries, as do a number of other vendors.) The OID and SunOne results are from benchmarks performed for a customer's RFP, and unfortunately are confidential. But you can find comparable results here:
The FedoraDS codebase is still much the same as SunOne. OpenLDAP is more scalable and higher performing than all others. Since you claim to have worked with all of these it should be no trouble for you to benchmark OpenLDAP against any of your other installations and verify for yourself. Unlike closed-source vendors who use license agreements to prevent you from publishing benchmark results for their products, you have total freedom to bench and publish your results with OpenLDAP...
You may not think it's taking the world by storm; the interesting thing is that it's going into more places than you're aware of. You just don't hear about it much because most companies are too embarrassed to admit they're running free software instead of the crap they spent millions on purchasing in their previous fiscal years.
Wrong. OpenLDAP is the number one top performing directory software in the world, and has been since 2003. None of the other directory vendors have been refreshing their technology in recent years, and OpenLDAP is generally 2-3x faster than everyone else. 5x faster than AD typically. If you want performance, eDirectory is pathetic in comparison, and even Novell's engineers have admitted they can't get anywhere close to OpenLDAP's performance.
To the folks saying "ActiveDirectory is best of breed" - yeah right. The AD server is crap; what you guys are seeing as "nice" are the GUI admin tools. Which by the way also work with Samba4/OpenLDAP...
I can't dispute that M$ makes slick GUIs (sometimes). But to call AD best at anything is a far stretch. And no pretty GUI on top is worth anything when the underlying technology is broken.
re: commercial support for OpenLDAP - Symas has customers with production deployments of billions of entries (several hundred million identities plus ancillary objects). OpenLDAP has been run successfully with over 5 billion entries in a single database; no other directory software in the world can make that claim. Oracle OID comes close but again at over an order of magnitude slower performance.
Telcos, cable companies, large financial institutions, petrochemical/energy companies, and governments all around the world are switching to OpenLDAP because it's the only solution that works reliably and performs so well at such large scales. Nothing else touches it.
Except, downloading copyrighted material isn't inherently wrong, by any definition, let alone illegal.
I was using an earlier version of get_iplayer's hulu support to catch up on TV shows that I'd missed recently. I'm also a cable TV subscriber - I've already paid for the right to receive and view these programs in my home. I've never signed any agreement that dictated how / in what form I can receive those programs, or whether I can record them or watch them later or not. They have my license fee, so now they should shut up and let me watch the material I already paid for.
Downloading for the purpose of unlicensed distribution - that's a separate matter. But that's not what I'm doing, and just trying to discourage people from downloading is misguided.
"make no difference" try profiling some actual code before you say that. I have, it does. It's the difference between having a poky slow AppleShare server and having the fastest one in the world. (Yes, I wrote that while at Locus Computing.) It's the difference between having a poky slow LDAP server and having the fastest one in the world. (Yes, I wrote that - OpenLDAP today is the world's fastest directory server; in 2000 it was a pig.)
Efficiency *always* matters. People who think "it makes no difference" are the programmers responsible for all the crap bloatware in the world today... Just because they're in the majority doesn't make them right.
You and the vast majority of C programmers, it seems.
Security aside, think of it from an efficiency perspective: it always starts from the beginning of the target string (since it has no other information available to it), iterates to the end, and then begins catenating the second string. This gives you O(n^2) behavior when catenating multiple times to the same string. The str* functions are some of the worst ever designed...
There are two obvious fixes:
1) always record explicit lengths of your strings, so that you can catenate by just memcpying to the end of a given target string
2) use my strcopy() function, which returns the pointer to the terminating NUL at the end of the target string.
E.g., this is legal and useful: strcat(strcat(strcpy(a,b),c),d);
but it's slow because each strcat starts over from the beginning. If strcpy/strcat always returned the pointer to the end of the target string, instead of the pointer to the beginning of the target string (which is what strcopy() does) then you get no efficiency loss, and you only need one function instead of two:
strcopy(strcopy(strcopy(a,b),c),d);
After you fix this basic inefficiency you can of course define strn/strl variants as you see fit...
Oddly enough, I have to agree with Drepper here, strcat() et al are terrible, and anyone using them *does* deserve to be punished. (Odd because of the many other disagreements I've had with him, on bug 4980 and elsewhere.)
But what do I know, it's not like I ever maintained a C compiler, high performance C library or multitasking kernel before. (Oh wait, I did...)
Author: Allan Bricker
Author: Morgan Clark
Author: Tad Lebeck
Author: Barton P. Miller
Author: Peter Wu
Title: Experiences with DREGS
Pages: 471-481
Publisher: USENIX
Proceedings: USENIX Conference Proceedings
Date: Summer 1987
Location: Phoenix, AZ
Institution: University of Wisconsin
dunno if it's available anywhere online now... I seem to recall that "DREGS" stood for Distributed Realtime Environment for Game Systems but that was ~22 years ago, not really sure any more.
Back in 1987 or so I saw a presentation at the Usenix conference about a new distributed computing project. One of the programs they adapted to their API was hack 1.0.2, which they called dhack. It was basically real-time, but you could save your game and resume it. Your character would be recorded as an indestructible statue until you resumed. I had just ported hack 1.0.3 to my Atari ST recently, and tried to get hold of their patches but they never published their source code. A shame. After a while I gave up and got hooked on Xtrek... (I had also ported several other similar games - Larn and Moria as I recall...)
I also split my Hack 1.0.3 source up into a game engine and a UI, so that I could run the curses interface remotely over the network, or use a graphical/tiled interface. I had plans to do a multiplayer version using timed turns (e.g., you can issue X commands per second) kind of like Trek73, but when Trek83 and Xtrek turned up I stopped messing with Hack...
Slashdot Mirror
rtmpdump decodes the majority of RTMP streams in common use today. We know what the other (currently unsupported) options are doing in general; it just isn't worth the time right now to fully decode them until they become more of an inconvenience to more people. (Or in other words, until they become an inconvenience to the rtmpdump developers...)
rtmpe is fundamentally flawed, broken by design. Unlike SSL/TLS it is vulnerable to M-I-T-M attacks and always will be. Any new mechanisms Adobe layers on top of it can be trivially broken with the application of a few hours of CPU time. (In contrast, breaking TLS still requires thousands to millions of hours of CPU time.)
False. With RTMP you can only seek to key frames. If you seek to a timestamp that doesn't correspond to a keyframe, the server will pick the nearest keyframe using some undisclosed algorithm. (I.e., it is not specified anywhere whether it will pick the closest keyframe *before* or *after* the designated seek timestamp.)
Obviously you can't start playback from a non-keyframe, there isn't enough video data to construct a full frame.
I dunno, preserving your company's reputation and credibility ought to be big enough motivators already. The fact that Adobe code quality is still so shoddy indicates that regardless of motivation, they lack the *ability* to improve things.
Btw, for video streaming, you can just use things like get-flash-videos and rtmpdump, and never be exposed to any of that crappy Adobe code. Whether or not the base technology has any intrinsic merit, it's obvious that even today, before HTML5 is widely deployed, it's possible to implement this stuff without any of Adobe's implementation flaws.
What makes you think that a mobile version needs to be any different from the current version?
I can watch Hulu videos on my Android phone just fine...
http://forum.xda-developers.com/showthread.php?p=5253967
Why would you volunteer to pay for something "extra" that isn't actually any extra effort on their part?
Windows-anything handling your money is Just Not a Good Idea.
http://www.flickr.com/photos/27159137@N08/3186737368/
Aside from the fact that this isn't news, it hasn't been a problem either. The patch to add the so-called "DRM" support to XBMC was made available within a few hours of the BBC change.
http://trac.xbmc.org/ticket/8971
So what no one seems to have asked yet - when is someone going to take a fertilized human egg, and remove these viral sequences from the nucleus, and see how the embryo is affected?
Take the embryo after the first division, so you can have an identical twin as a control for the experiment...
But it took NASA to develop SAR and refine its use. I worked on the control software for SIR-C back in 1991-1994; all of the software that I wrote for that got re-used by RADARSAT and SRTM and probably other missions as well. (Haven't really kept tabs after I left.)
Aside from the other stupidity already being commented on, this is purely a case of bad design in the LED traffic signals. LEDs are ~4x more efficient than incandescents, but they're still far from perfect, and they still give off a *lot* of heat.
http://en.wikipedia.org/wiki/Luminous_efficacy
I've designed and built many lamps using high power/high brightness LEDs. Any time you design a high power LED lamp you have to heat-sink every single LED otherwise it will burn out. The obvious solution here is to run heatpipes from the sinks at the back of the LEDs to the lamp housing and/or front lens. There's no need to add a separate heater, every electronic device *is* a heater.
http://code.google.com/p/get-flash-videos/
works great, covers a ton of sites already, and is easily extensible to add support for any new sites.
And yes, I agree with several of the posters above - I don't want to watch videos inside my browser; I don't want the distraction of multiple animated ads on the borders of the page etc...
this weekend large portions of Spain suffered extended blackouts as a number of the electric company's network routers were overwhelmed by an unexpected surge of traffic. This was apparently the result of an article about Spain's wind-based electrical program being published on slashdot.org, and the ensuing traffic overload from attempts to access the power generation graphs on the public site...
$33? You can buy a tube of IC Diamond for only $7. DIY isn't too interesting when it costs so much more than off-the-shelf...
Agreed. This was from last December in Kazakhstan, by the way:
http://www.flickr.com/photos/27159137@N08/3186737368/
About the same time frame as those researchers and their discovery. Seems to me that this type of hacking has been going on all over, for a long time already.
And yes, I'd say it's criminally negligent to use any Windows OS on ATMs or anything else where security matters...
It's not so surprising though - it just means that the ants have been able to spread faster than their rate of evolution/mutation. Otherwise, they would have differentiated/speciated first. But because it's so easy for them to hitch rides on passing people, cars, boats, and airplanes, they've spread a lot faster than they would naturally have been able to.
The more interesting thing will be to observe over time and see how long it takes before their super-colony collapses or is torn apart by civil war. Of course that's not likely to occur until their paths of transport and communication are disrupted. If we don't destroy ourselves first, thus giving them a long time to continue to evolve in total connectedness, I guess things will get interesting for them down the road...
The other interesting point this raises is about language and communication in general - biologists frequently talk about animals communicating with each other via whatever their particular mechanisms may be, but they seem to assume that all the members of a species are homogeneous in their communication methods. That's a pretty naive assumption, given all the different vocal and non-vocal mechanisms various human tribes use to communicate. The interesting question here will be whether this super-colony is an example of genocide (the total annihilation of different/competing ant species) or assimilation...
What's to code? OpenLDAP already supports over 5 billion user records...
I sometimes get to a point where I want to sketch out the problem on paper, but most of the time as I'm searching for a pen or pencil, and a decent sheet of paper, I've already figured out what it will look like in my head, and I quit searching.
By the way...
http://www.networkcomputing.com/channels/security/showArticle.jhtml?articleID=199901451&pgno=5
OpenLDAP is #2 to AD in the Fortune 500, all of the other vendors you mention are down in the noise.
Sorry, the eDirectory info is based on personal communication from a Novell engineer. (But it's worth noting that OpenLDAP's libraries are also better tuned than anyone else's, and Novell now ships OpenLDAP's libraries, as do a number of other vendors.) The OID and SunOne results are from benchmarks performed for a customer's RFP, and unfortunately are confidential. But you can find comparable results here:
http://www.connexitor.com/blog/pivot/entry.php?id=130
The FedoraDS codebase is still much the same as SunOne. OpenLDAP is more scalable and higher performing than all others. Since you claim to have worked with all of these it should be no trouble for you to benchmark OpenLDAP against any of your other installations and verify for yourself. Unlike closed-source vendors who use license agreements to prevent you from publishing benchmark results for their products, you have total freedom to bench and publish your results with OpenLDAP...
You may not think it's taking the world by storm; the interesting thing is that it's going into more places than you're aware of. You just don't hear about it much because most companies are too embarrassed to admit they're running free software instead of the crap they spent millions on purchasing in their previous fiscal years.
Wrong. OpenLDAP is the number one top performing directory software in the world, and has been since 2003. None of the other directory vendors have been refreshing their technology in recent years, and OpenLDAP is generally 2-3x faster than everyone else. 5x faster than AD typically. If you want performance, eDirectory is pathetic in comparison, and even Novell's engineers have admitted they can't get anywhere close to OpenLDAP's performance.
To the folks saying "ActiveDirectory is best of breed" - yeah right. The AD server is crap; what you guys are seeing as "nice" are the GUI admin tools. Which by the way also work with Samba4/OpenLDAP...
AD design flaws: http://www.mail-archive.com/ldap@umich.edu/msg01464.html
I can't dispute that M$ makes slick GUIs (sometimes). But to call AD best at anything is a far stretch. And no pretty GUI on top is worth anything when the underlying technology is broken.
re: commercial support for OpenLDAP - Symas has customers with production deployments of billions of entries (several hundred million identities plus ancillary objects). OpenLDAP has been run successfully with over 5 billion entries in a single database; no other directory software in the world can make that claim. Oracle OID comes close but again at over an order of magnitude slower performance.
Telcos, cable companies, large financial institutions, petrochemical/energy companies, and governments all around the world are switching to OpenLDAP because it's the only solution that works reliably and performs so well at such large scales. Nothing else touches it.
Except, downloading copyrighted material isn't inherently wrong, by any definition, let alone illegal.
I was using an earlier version of get_iplayer's hulu support to catch up on TV shows that I'd missed recently. I'm also a cable TV subscriber - I've already paid for the right to receive and view these programs in my home. I've never signed any agreement that dictated how / in what form I can receive those programs, or whether I can record them or watch them later or not. They have my license fee, so now they should shut up and let me watch the material I already paid for.
Downloading for the purpose of unlicensed distribution - that's a separate matter. But that's not what I'm doing, and just trying to discourage people from downloading is misguided.
What other use case *is* there for strcat???
"make no difference" try profiling some actual code before you say that. I have, it does. It's the difference between having a poky slow AppleShare server and having the fastest one in the world. (Yes, I wrote that while at Locus Computing.) It's the difference between having a poky slow LDAP server and having the fastest one in the world. (Yes, I wrote that - OpenLDAP today is the world's fastest directory server; in 2000 it was a pig.)
Efficiency *always* matters. People who think "it makes no difference" are the programmers responsible for all the crap bloatware in the world today... Just because they're in the majority doesn't make them right.
You and the vast majority of C programmers, it seems.
Security aside, think of it from an efficiency perspective: it always starts from the beginning of the target string (since it has no other information available to it), iterates to the end, and then begins catenating the second string. This gives you O(n^2) behavior when catenating multiple times to the same string. The str* functions are some of the worst ever designed...
There are two obvious fixes:
1) always record explicit lengths of your strings, so that you can catenate by just memcpying to the end of a given target string
2) use my strcopy() function, which returns the pointer to the terminating NUL at the end of the target string.
E.g., this is legal and useful:
strcat(strcat(strcpy(a,b),c),d);
but it's slow because each strcat starts over from the beginning. If strcpy/strcat always returned the pointer to the end of the target string, instead of the pointer to the beginning of the target string (which is what strcopy() does) then you get no efficiency loss, and you only need one function instead of two:
strcopy(strcopy(strcopy(a,b),c),d);
After you fix this basic inefficiency you can of course define strn/strl variants as you see fit...
Oddly enough, I have to agree with Drepper here, strcat() et al are terrible, and anyone using them *does* deserve to be punished. (Odd because of the many other disagreements I've had with him, on bug 4980 and elsewhere.)
But what do I know, it's not like I ever maintained a C compiler, high performance C library or multitasking kernel before. (Oh wait, I did...)
Found the reference I was talking about:
Author: Allan Bricker
Author: Morgan Clark
Author: Tad Lebeck
Author: Barton P. Miller
Author: Peter Wu
Title: Experiences with DREGS
Pages: 471-481
Publisher: USENIX
Proceedings: USENIX Conference Proceedings
Date: Summer 1987
Location: Phoenix, AZ
Institution: University of Wisconsin
From here http://usenix.org/publications/bibliography/byDate.html
dunno if it's available anywhere online now...
I seem to recall that "DREGS" stood for Distributed Realtime Environment for Game Systems but that was ~22 years ago, not really sure any more.
Back in 1987 or so I saw a presentation at the Usenix conference about a new distributed computing project. One of the programs they adapted to their API was hack 1.0.2, which they called dhack. It was basically real-time, but you could save your game and resume it. Your character would be recorded as an indestructible statue until you resumed. I had just ported hack 1.0.3 to my Atari ST recently, and tried to get hold of their patches but they never published their source code. A shame. After a while I gave up and got hooked on Xtrek... (I had also ported several other similar games - Larn and Moria as I recall...)
I also split my Hack 1.0.3 source up into a game engine and a UI, so that I could run the curses interface remotely over the network, or use a graphical/tiled interface. I had plans to do a multiplayer version using timed turns (e.g., you can issue X commands per second) kind of like Trek73, but when Trek83 and Xtrek turned up I stopped messing with Hack...