A 23 millon grant from Exxon you say? You mean, like ~0.05% of their profit? Yeah, sound like they're sending the big money to the climate researchers.
Well, it's basically the problem with the duality of word "Play". Play can mean play is in a playdate or playful, and it can mean play as in playing football, ranging everything for between a simple handclapping-games, to serious "when I loose my life is over" competition.
Different players want different things, and as long as there's a plethora of options, I'm happy.
Ideas is not subject to copyright but definitely protected by intellectual property laws in many countries. The famous double-click patent, or patent on streaming media, downloading, or blinking text-marker comes to mind.
Hi, we skimmed through OpenNMS during our initial survey of the Open Source market. Back then (roughly 9 months ago) we discarded OpenNMS since it did not seem to match our scope. The Network monitoring requirement is for us very low, we need much more host and service-monitoring, and OpenNMS did not seem like the right tool back then.
Now, after a tip earlier in this article and reading a little deeper about OpenNMS, it definitely seems like a strong candidate, and I will investigate further when I get back to work.
Just one question, I can't easily figure from the website just exactly HOW host monitoring is attempted? I.E. detecting harddrive-failure, filesystem-conditions, load etc. I realise it could be setup as a big bunch of services and monitored indiviually, but that is exactly one of the things we're trying to get away from in our current solution (Argus).
Regarding "The Perfect Monitoring System", I hear there will be one, slated for simultaneous release with Duke Nukem Forever.;)
Yeah, maybe saying ZODB not being solid is not being completely fair, and a bit imprecise.
The thing I experienced as a problem with our ZenOSS attempts wasn't ZODB by itself. We had no reason to believe ZODB by itself was corrupted, just that something had gone wrong, and was recorded in the ZODB.
The problem I see with ZODB is not it's own merits, but how it tends to get used. If I develop software for working with some established RDBMS-backend, I'm pretty much forced to remember that someone else may very well enter and change data out of my control, change data-structures, add columns for it's own private use and so on. The SQL database is basically a shared database, which means I must be more wary on how I insert and fetch stuff, and thinking about the corner-cases a bit more. (And also preferably document and be explicit about my database model.)
In the ZODB-option, or basically any database that is not easily considered as may being shared with other apps or easily directly accessible by the end-user, (SQLite falls into this category as well, despite being RDBMS and SQL), I more easily assume that what is found in the database is only what my app put there. Thus, I'm less forced to expect oddities in the database (such as reference to a missing key, as was the case in my last issue with ZenOSS). This all leads to my implementation getting more prone to have a lot of assumptions, such as the "object invariants" you mention, and we all know what offspring assumptions yield.
So, the problem here is not the stability, or lack of features, or any problem technically caused by ZODB itself, but that since it's not something that even an advanced user is likely to poke around in, it easily leads to naive implementations, which makes all problems more or less a black-box-problem (even if you have the source-code, and technically CAN poke around freely in the database).
So, the problem is one of mindset, and a little about easy to tools to directly access the database, but not any technical fault in ZODB itself.
Hmm, and it seems you didn't really read the part in my posting about event-handling. Syslog-handling and SNMP trap decoding is _very_ important for us, since we have a lot of black-box equipment whose only interface is SNMP, and half of the information comes as traps and can't be polled.
It is true that we did not evaluate BixData, but judging from the web-site, it also does not match what we're looking for. If you remove the SNMP/Syslog-requirements, there are more solutions that does roughly what BixData seems to do, like Zabbix, or maybe even Nagios would be a serious contender in that game.
Sorry, I don't have a suggestion. That's basically the point of my posting, none of the current (open source, that we found) monitoring systems really serves our needs. (Although yours may be different story.)
Currently, we are doing a closer evaluation of Zabbix, which is so far looking OK for the parts it does solve (although to be fair, we haven't yet reached the full-implementation-attempt where ZenOSS started failing us).
Zabbix however, lacks the event-handling parts we need (listen to and manage remote syslogs and SNMP traps), so we are attempting a combination with rsyslog + phplogcon and a bunch of own-written scripts for dispatching to cell-phone / e-mail based on a rule-set. It will be a big hairy ball of glue and duct-tape and will be lacking a lot of highly valued features, but in time, we may end up with a solution we can work with.
My/dev/null is light and very fast to write to. Just remember though, when you want to find that data, you'll find it have magically been moved to/dev/urandom. Be wary though, since/dev/urandom actually encrypts the data for you, it is just THAT cool! To decrypt, it's really simple, you just read a chunk X from/dev/urandom, and the same chunk Y from the original data, and do X XOR X XOR Y, and wee, you've just stored infinite amounts of data in under one gram!
I just did a quick survey and evaluation of the open source monitoring-market for my company, and found a few shortcomings/frustrations in a few aspects where none of the evaluated system seems to get it 100% right.
Transparent Planned Design Many solutions out there seems to have been developed in what can only be described as an "organic" process. I.E. a few scripts were used from start, were hooked up with some other scripts, were slammed into a web-interface, got some more features, then something central were ripped out and replaced to allow yet more features and so on and so forth. (Read: Nagios) While this is of course often the best way to get something working for a particular need, and on a tight budget, it makes adoption really hard unless you happen to have exactly the same need.
Event management Does anyone know a solution that can both receive from syslog and decode traps with a given MIB, and then do some simple logic, like squashing repeats, displaying on a web-page with archival-options, and dispatch to mail/sms based on configurable rules? Except for ZenOSS (and ZenOSS have other problems), I haven't found a single sensible system that does this.
Modularity/Seamless Integration Since much of the monitoring systems out there doesn't seem to have a clear design, it's often very hard to add missing features. I.E. project X missing an event manager, or is the builtin not satisfactory? No probs, I'll just, ehh, where does this wire come from? Is this really a socket? Did anyone really connect that? It's ok with blackbox-solutions, as long as they serve all my needs, and have clear interfaces to combine with other solutions that serves related needs, but sadly no solution evaluated does everything we need it to and we end up struggling with manual routines to compensate for it.
Complexity There are a few really neat systems that does almost everything one can ask for. (Short of flying cars). Unfortunately, the ones we've tried have always turned out to be very complex, and also do a lot of things we didn't want. Since it's then often not very modular, it hard to get it stop doing the things we don't want, or change the things we need implemented slightly differently. Also the huge codebase that comes along with trying to scratch everyones itch seems to get it's share of bugs, and troubleshooting in large more or less opaque systems is not a fun task.
The Perfect Monitoring System After evaluating all options we could find, we've come to the conclusion that none of the systems we've looked at or tested really fits our needs (Although ZenOSS came close, we encountered just too many bugs and oddities to keep investing time in it). Furthermore, we could not find a combination of systems that integrates well, and together fits our needs, which I personally see as a bigger problem.
What I would really want to see in the world of Open Source Monitoring, is an eco-system of monitoring apps with an overarching design/architecture. Design a framework where different entities and steps in the monitoring are clearly defined and interfaced with each other, but still allows for differing implementations, and integration with unforeseen needs. For example, at our shop, we continuously analyze roughly 700mbit of streaming video for availability and quality. Noone designing a monitoring system could probably forsee this as an appliance, but in The Perfect Monitoring System, it should be clear for the average-skilled hacker how to integrate it.
ZenOSS may be great, but a word of warning. We've had 3 failed attempts at implementing it in our shop. What we tried to achieve was mainly host and service-monitoring, with some slight network-monitoring on the side. Nothing fancy, just some 20 hosts, maybe 30 network-devices, and a variety of services.
One of the major parts we've found missing in most open-source solution was proper event-management (recieving syslog + snmp traps, and apply some intelligence to it regarding flow control, dispatching, archival and that stuff.) ZenOSS is on paper, and throughout the initial evaluation one of the best open source tools to do this.
However, during our three attempts to get it up and running, we've always encountered some major obstacle (usually after a while of operation), forcing us to start all over from scratch. The problems we had was always in the same category, strange and unexplainable errors, often hard to reproduce, and in general it resulted in a very flaky experience. Some of the problems have been service-checks showing both false positives and false negatives, and in the last problem ZenOSS refused to import new SNMP MIB:s, complaining about some IP-address that could not be found anywhere in the config, and grepping ultimately found the IP to be only present somewhere in the opaque zope-database, where evidently it could not easily be removed, nor even found exactly what the ip-address was for. (It was something auto-discovered in a remote network segment out of our control, but advertised throughout the routers.)
So, while ZenOSS can do all kinds of things, and does a LOT of things really well, it's extremely complex, not in all parts on solid foundation (such as all network objects in a non-accessible Zope-database that the devs themselves recommends not touching since it may upset things more). If you plan on implementing ZenOSS, I would not go without the support, which I assume is great, since there seems to be quite some dark pits to fall in on your own.
I dont know how come we had so much obstacles and strange problems when others seem to have a smooth ride. Maybe one explanation is what were the final nail in the coffin for ZenOSS in our deployment. When I started asking around about these problems (and ZenOSS has a really helpful community, no problems there), I realised that many users claimed to have gotten into similar problems that we had, but their solution were to just keep daily backups, and revert to a backup when they ran into these problems. For us, the monitoring data is basis for a lot of 3d-party agreement, and loosing even days worth of monitoring and logging is completely unacceptable due to these reasons. We do backup everything, but in case of rare disasters, and we must be able to rely on the monitoring system giving us a clear view through those disasters.
Interestingly, sites implementing H.264 will not really find a big market. (At least, initially). According to http://en.wikipedia.org/wiki/Usage_share_of_web_browsers and it's sources, 1 out of 10 users actually run a browser that will support the video-tag with h.264 in the near future. The Theora combo on the other hand will soon be supported by for 1 in 4 viewers.
It will be interesting to see how this plays out. My guess is a combo. It should not be difficult to figure using Javascript what type of device you're running on, and deliver full-resolution Theora content for desktops (where Firefox is king of the HTML5-gang), and lower-resolution H.264 for handhelds. (I assume content-site will still would probably want different bitrates and resolutions for handhelds.)
Another interesting aspect is what the numerous smaller streaming-sites will go with. They may not want to pay a H.264 license. Maybe we're going to start seeing the "Site works best with browser X"-stamps again, and there is really only one browser that is platform-neutral and will work equally well for the 10% Mac-users, as for the 88% Windows-users, and the 2% others. Interesting times, it was almost 10 years since we really saw a full-out browser war.
That's what I'm afraid of. The big performance wins have never been in the final optimization-phase, but in doing a design aimed for performance, utilizing better algorithms to reduce resources spent.
Good thing programmers are now encouraged to think even less about that. "Oh, the compiler will probably optimize that away, and it's more readable like this."
1 - Microsoft Internet explorer > 50% Have no outspoken plans of supporting anyways. So according to the arguments of the parent, W3C should remove alltogether.
2 - Mozilla Firefox 20-30 % Strongly suggests implementing Theora, since h.264 is a real indisputable impossibility due to the licensing part.
3 - Apple Safari ~3-8 % Says they do not want to implement Theora due to fears of patent trolls, pushing H264.
4 - Google Chrome ~2 % (note, is rising the fastest of all right now) Will support both.
Conclusion; according to parent, either the tag should be dropped since the biggest browser vendor won't implement it. If there is nothing mandated, then content vendors will probably go on with flash (maybe that's the case anyways). In either case a specification cannot JUST implode to the least common denominator that happens to be already implemented, or progress will only continue to happen in proprietary-land, not the land of fair competition.
Actually, I wrote ghz first, but realized (when I was done with the entire post) I were a couple of years behind so doubled everything to more easily adjust stuff.;)
Also 4ghz != 4 million instructions/second, which is a typo (clarified below).
In other words; two errors in one sentence. Can only be accomplished while watching the sun rise after not sleeping for a night.;)
Basically, it says how long it would take to be sure to crack it.
To give a comparison, most machines on the net today is clocked at ~4Ghz, that is 4 000 000 000 instructions per second. Imagine a CPU:s doped for only one thing, and one cpu-cycle would mean one key tested ( in reality, there's more like maybe 1000s of cycles/test or something like that ). That would mean that the cpu crunched 172 000 billions of tests per day. With that monster cpu, it would still take 5 billions of billion years to be sure to crunch that encryption.
Even if you filled the theoretical limits of todays internet (unfortunately, IPv6 is still the internet of tomorrow) with these monster machines, it would still take 1,25 billon years to be sure to find the key. This all is of course just theory. Who knows, if you're lucky you may get it in a tenth of that time, only 125 million years.;)
As a footnote, for the cost of those monster-machines, the operational cost of them and the staff to support them, you'd be much better off bying an army. Physical security in most places is much weaker than AES currently, so it would be much easier just to force the secrets out.
Disclaimer: All this assumes turing-machines, where only one solution at a time can be evaluated. In a quantum-processor, you could theoretically do much better.
Actually, that gives me an idea. Couldn't anyone write a modification to adblock that does this automatically? Basically, you enter a whitelist of companies you want to punish, and whenever adblock sees what looks like one of their ads, it simulates a click in the background, that you're not forced to see?
Encourage a few users to install, and it would start getting noticable.:) While I truly believe ads as such are good for the web as a whole, some ads and ad-driven sites (especially all things Flash) should be punished for ruining my user-experience with blinking crap getting all in the way all the time, even sometimes intentionally trying to trick the user into clicking the wrong links.
Good security involves locking out the user after a certain number of attempts in order to stop a "dictionary attack". I just had to reset a users PW twice this afternoon because she locked herself out of her account. Sure, it's extra hassle but the security is worth it.
That's probably due to poor configuration of the security-measures. You should enforce reasonable passwords being used (the usual, at least 8 characters, with at least 1 character being a digit.) Given that, it will likely take at least 100s of attempts for an attacker, which means you should be safe allowing some 15-20 attemps from the user, which very few users actually would use up before asking for a replacement password.
If the user still fails with those attempts, maybe giving him/her a blank password is the best option, since any security is obviously too unusable for him/her anyways.
I was tired, in a hurry, and I didn't get the HTML-formatting, or the plain-text-mode to respect my paragraphs (which, trust me, a LOT less readable than the monospace-stuff).:)
About the theora not following bitrate, yeah, I discovered that too, a minute after posting this. *fail*
Still though, if you want to compare codecs, you've got to ensure the codecs are run under similar conditions (GOP-size, number of passes, etc.). Driving them in different pipelines (ffmpeg, with tuned x264 as compared to ffmpeg2theora) is far from ideal in that respect.
I work for a television distributor, and half a year ago, we had a customer complaining that we were encoding our MPEG-4-streams with too high bitrate, claiming that other encoders could achieve the same quality at only half the peak bitrate. After investigation, we discovered that he had run the other encoder with 15-second GOP, which in broadcast would infer up to 15 seconds zap-time (time to get a picture when zapping to a channel). So those parameters really do matter for encoder performance, but they are still not always desirable to tune to maximum.
Wow, I just had to comment on this. The article itself is of course nice and intriguing (and the video-clip chosen is an excellent clip to give the codec a hard-time. The grass, and medium-mask net in the background, wow.)
The problem with the article is that it really compares pears with apples, and is not too specific about what pears and what apples. The main problem here is that is uses different suites for conversion, in one hand ffmpeg with some probably well-tuned defaults for x264 (-vpre hq), and on the other hand ffmpeg2theora, that may be tuned for different defaults and different coding-settings. Especially, there are two parameters not covered by the article that may have a huge impact. Multipass-encoding, and keyframe-density.
Multipass-encoding is a technique where you let the encoder skim the content several times, gatherings statistics on progressive levels. Multipass encoding has huge benefits, and can sometimes cut the mbit/quality in half, or more.
Keyframes are special frames in the video-stream where the content can be synced. Between those frames only progressive frames happen, so you can't skip to those frames. Keyframes usually take up a lot more space than the frames in between so you want as few as possible of those, but if you make them too few, you will be limiting seeking severly, and for live content, the zap-time will increase.
Then there's the issues of whether different processing filters were used between the sets, and of course exactly WHICH versions of the codecs were used. "June-something" isn't really a good spec.
To make it a bit more equal comparison, and also with known versions, I tried redoing it myself, using a gstreamer-pipeline and the same source-material used in the article. The pipelines used were:
Unfortunately, I don't have much time, or hosting space to share the encoded results, but trust me, it was NOT in favor of x264 with these settings. On the bright side, you can try it out for yourself, and fiddle with different settings, all versions are directly from updated Ubuntu Jaunty repositories, as of today. Just install gst-tools, and all gst-plugins even from multiverse.
The question is often made to be about whether the artist rights should be respected or not. That is just sad, I really think and hope that all but a minority actually would agree that naturally, creators should be respected and paid.
The real question is, exactly what rights should be held by the creator, and should the distribution-chain out to the customer be controlled somehow?
I.E.
* Is it really realistic to be able to retain rights for a creative work 20-70 years after the actual work was done?
? In the case of patents, how does this affect the market as a whole?
* Should distributors be required to warn about certain potential problems with their distribution methods, such as DRM-servers going offline, or your audio-cd discretely replacing an important piece of your driver-subsystem when you try to listen to some music.
* Many countries have some sort of defined "fair use" for creative works, but what exactly does that constitute?
? Can I lend a copy to a _real physical_ friend?
? What if the friend is a loose aquaintance on the net?
? Can I play it in class, or in a closed socitey, like an interest-club or similar?
? Am I allowed to record live broadcasts and watch later?
Many of these questions are getting waay too little attention today, so I'm glad the increased popularity of the pirate-party gives a big incentive for other parties to start caring.
A band called ABBA (or ABBA, if you prefer it backwards)
A car brand called Volvo (popularly used for smashing into things in Hollywood)
Something called IKEA (or maybe it's japanese)
Ericson as in Sony-Ericson (yeah, that's probably Ericson, the Spaniard famous for introducing sex-hot-lines across the Atlantic)
Oh, and then I suppose there's nothing else. So, you're probably right, why care that almost 8% of all voters in a small offside country thinks that the privacy/copyright/IP questions are more important than all other questions combined (you know, stuff like clean air, working agriculture and maybe some sort of healthcare).
The Pirate Party is nothing more than a bunch of college kids who want shit for free.
Interesting. Looking at their top 10 candidates for national government a few years back, you'll find that their average age is 38, and that 7/10 is 40 or older.
Among their top active public members, can be found an author, a musician, several with years of background in it consulting, one with a former background as director of a book publishing company, one with a background in national politics and a few with active backgrounds in other larger political parties.
So while some of the members are certainly cheap greedy kids as you describe them, clearly that does not constitute the entire party.
Slashdot Mirror
Or Spotify
A 23 millon grant from Exxon you say? You mean, like ~0.05% of their profit? Yeah, sound like they're sending the big money to the climate researchers.
http://www.msnbc.msn.com/id/22949325/
Well, it's basically the problem with the duality of word "Play". Play can mean play is in a playdate or playful, and it can mean play as in playing football, ranging everything for between a simple handclapping-games, to serious "when I loose my life is over" competition.
Different players want different things, and as long as there's a plethora of options, I'm happy.
Ideas is not subject to copyright but definitely protected by intellectual property laws in many countries. The famous double-click patent, or patent on streaming media, downloading, or blinking text-marker comes to mind.
Hi, we skimmed through OpenNMS during our initial survey of the Open Source market. Back then (roughly 9 months ago) we discarded OpenNMS since it did not seem to match our scope. The Network monitoring requirement is for us very low, we need much more host and service-monitoring, and OpenNMS did not seem like the right tool back then.
Now, after a tip earlier in this article and reading a little deeper about OpenNMS, it definitely seems like a strong candidate, and I will investigate further when I get back to work.
Just one question, I can't easily figure from the website just exactly HOW host monitoring is attempted? I.E. detecting harddrive-failure, filesystem-conditions, load etc. I realise it could be setup as a big bunch of services and monitored indiviually, but that is exactly one of the things we're trying to get away from in our current solution (Argus).
Regarding "The Perfect Monitoring System", I hear there will be one, slated for simultaneous release with Duke Nukem Forever. ;)
Yeah, maybe saying ZODB not being solid is not being completely fair, and a bit imprecise.
The thing I experienced as a problem with our ZenOSS attempts wasn't ZODB by itself. We had no reason to believe ZODB by itself was corrupted, just that something had gone wrong, and was recorded in the ZODB.
The problem I see with ZODB is not it's own merits, but how it tends to get used. If I develop software for working with some established RDBMS-backend, I'm pretty much forced to remember that someone else may very well enter and change data out of my control, change data-structures, add columns for it's own private use and so on. The SQL database is basically a shared database, which means I must be more wary on how I insert and fetch stuff, and thinking about the corner-cases a bit more. (And also preferably document and be explicit about my database model.)
In the ZODB-option, or basically any database that is not easily considered as may being shared with other apps or easily directly accessible by the end-user, (SQLite falls into this category as well, despite being RDBMS and SQL), I more easily assume that what is found in the database is only what my app put there. Thus, I'm less forced to expect oddities in the database (such as reference to a missing key, as was the case in my last issue with ZenOSS). This all leads to my implementation getting more prone to have a lot of assumptions, such as the "object invariants" you mention, and we all know what offspring assumptions yield.
So, the problem here is not the stability, or lack of features, or any problem technically caused by ZODB itself, but that since it's not something that even an advanced user is likely to poke around in, it easily leads to naive implementations, which makes all problems more or less a black-box-problem (even if you have the source-code, and technically CAN poke around freely in the database).
So, the problem is one of mindset, and a little about easy to tools to directly access the database, but not any technical fault in ZODB itself.
Hmm, and it seems you didn't really read the part in my posting about event-handling. Syslog-handling and SNMP trap decoding is _very_ important for us, since we have a lot of black-box equipment whose only interface is SNMP, and half of the information comes as traps and can't be polled.
It is true that we did not evaluate BixData, but judging from the web-site, it also does not match what we're looking for. If you remove the SNMP/Syslog-requirements, there are more solutions that does roughly what BixData seems to do, like Zabbix, or maybe even Nagios would be a serious contender in that game.
Sorry, I don't have a suggestion. That's basically the point of my posting, none of the current (open source, that we found) monitoring systems really serves our needs. (Although yours may be different story.)
Currently, we are doing a closer evaluation of Zabbix, which is so far looking OK for the parts it does solve (although to be fair, we haven't yet reached the full-implementation-attempt where ZenOSS started failing us).
Zabbix however, lacks the event-handling parts we need (listen to and manage remote syslogs and SNMP traps), so we are attempting a combination with rsyslog + phplogcon and a bunch of own-written scripts for dispatching to cell-phone / e-mail based on a rule-set. It will be a big hairy ball of glue and duct-tape and will be lacking a lot of highly valued features, but in time, we may end up with a solution we can work with.
My /dev/null is light and very fast to write to. Just remember though, when you want to find that data, you'll find it have magically been moved to /dev/urandom. Be wary though, since /dev/urandom actually encrypts the data for you, it is just THAT cool! To decrypt, it's really simple, you just read a chunk X from /dev/urandom, and the same chunk Y from the original data, and do X XOR X XOR Y, and wee, you've just stored infinite amounts of data in under one gram!
I just did a quick survey and evaluation of the open source monitoring-market for my company, and found a few shortcomings/frustrations in a few aspects where none of the evaluated system seems to get it 100% right.
Transparent Planned Design
Many solutions out there seems to have been developed in what can only be described as an "organic" process. I.E. a few scripts were used from start, were hooked up with some other scripts, were slammed into a web-interface, got some more features, then something central were ripped out and replaced to allow yet more features and so on and so forth. (Read: Nagios) While this is of course often the best way to get something working for a particular need, and on a tight budget, it makes adoption really hard unless you happen to have exactly the same need.
Event management
Does anyone know a solution that can both receive from syslog and decode traps with a given MIB, and then do some simple logic, like squashing repeats, displaying on a web-page with archival-options, and dispatch to mail/sms based on configurable rules? Except for ZenOSS (and ZenOSS have other problems), I haven't found a single sensible system that does this.
Modularity/Seamless Integration
Since much of the monitoring systems out there doesn't seem to have a clear design, it's often very hard to add missing features. I.E. project X missing an event manager, or is the builtin not satisfactory? No probs, I'll just, ehh, where does this wire come from? Is this really a socket? Did anyone really connect that? It's ok with blackbox-solutions, as long as they serve all my needs, and have clear interfaces to combine with other solutions that serves related needs, but sadly no solution evaluated does everything we need it to and we end up struggling with manual routines to compensate for it.
Complexity
There are a few really neat systems that does almost everything one can ask for. (Short of flying cars). Unfortunately, the ones we've tried have always turned out to be very complex, and also do a lot of things we didn't want. Since it's then often not very modular, it hard to get it stop doing the things we don't want, or change the things we need implemented slightly differently. Also the huge codebase that comes along with trying to scratch everyones itch seems to get it's share of bugs, and troubleshooting in large more or less opaque systems is not a fun task.
The Perfect Monitoring System
After evaluating all options we could find, we've come to the conclusion that none of the systems we've looked at or tested really fits our needs (Although ZenOSS came close, we encountered just too many bugs and oddities to keep investing time in it). Furthermore, we could not find a combination of systems that integrates well, and together fits our needs, which I personally see as a bigger problem.
What I would really want to see in the world of Open Source Monitoring, is an eco-system of monitoring apps with an overarching design/architecture. Design a framework where different entities and steps in the monitoring are clearly defined and interfaced with each other, but still allows for differing implementations, and integration with unforeseen needs. For example, at our shop, we continuously analyze roughly 700mbit of streaming video for availability and quality. Noone designing a monitoring system could probably forsee this as an appliance, but in The Perfect Monitoring System, it should be clear for the average-skilled hacker how to integrate it.
ZenOSS may be great, but a word of warning. We've had 3 failed attempts at implementing it in our shop. What we tried to achieve was mainly host and service-monitoring, with some slight network-monitoring on the side. Nothing fancy, just some 20 hosts, maybe 30 network-devices, and a variety of services.
One of the major parts we've found missing in most open-source solution was proper event-management (recieving syslog + snmp traps, and apply some intelligence to it regarding flow control, dispatching, archival and that stuff.) ZenOSS is on paper, and throughout the initial evaluation one of the best open source tools to do this.
However, during our three attempts to get it up and running, we've always encountered some major obstacle (usually after a while of operation), forcing us to start all over from scratch. The problems we had was always in the same category, strange and unexplainable errors, often hard to reproduce, and in general it resulted in a very flaky experience. Some of the problems have been service-checks showing both false positives and false negatives, and in the last problem ZenOSS refused to import new SNMP MIB:s, complaining about some IP-address that could not be found anywhere in the config, and grepping ultimately found the IP to be only present somewhere in the opaque zope-database, where evidently it could not easily be removed, nor even found exactly what the ip-address was for. (It was something auto-discovered in a remote network segment out of our control, but advertised throughout the routers.)
So, while ZenOSS can do all kinds of things, and does a LOT of things really well, it's extremely complex, not in all parts on solid foundation (such as all network objects in a non-accessible Zope-database that the devs themselves recommends not touching since it may upset things more). If you plan on implementing ZenOSS, I would not go without the support, which I assume is great, since there seems to be quite some dark pits to fall in on your own.
I dont know how come we had so much obstacles and strange problems when others seem to have a smooth ride. Maybe one explanation is what were the final nail in the coffin for ZenOSS in our deployment. When I started asking around about these problems (and ZenOSS has a really helpful community, no problems there), I realised that many users claimed to have gotten into similar problems that we had, but their solution were to just keep daily backups, and revert to a backup when they ran into these problems. For us, the monitoring data is basis for a lot of 3d-party agreement, and loosing even days worth of monitoring and logging is completely unacceptable due to these reasons. We do backup everything, but in case of rare disasters, and we must be able to rely on the monitoring system giving us a clear view through those disasters.
Interestingly, sites implementing H.264 will not really find a big market. (At least, initially). According to http://en.wikipedia.org/wiki/Usage_share_of_web_browsers and it's sources, 1 out of 10 users actually run a browser that will support the video-tag with h.264 in the near future. The Theora combo on the other hand will soon be supported by for 1 in 4 viewers.
It will be interesting to see how this plays out. My guess is a combo. It should not be difficult to figure using Javascript what type of device you're running on, and deliver full-resolution Theora content for desktops (where Firefox is king of the HTML5-gang), and lower-resolution H.264 for handhelds. (I assume content-site will still would probably want different bitrates and resolutions for handhelds.)
Another interesting aspect is what the numerous smaller streaming-sites will go with. They may not want to pay a H.264 license. Maybe we're going to start seeing the "Site works best with browser X"-stamps again, and there is really only one browser that is platform-neutral and will work equally well for the 10% Mac-users, as for the 88% Windows-users, and the 2% others. Interesting times, it was almost 10 years since we really saw a full-out browser war.
That's what I'm afraid of. The big performance wins have never been in the final optimization-phase, but in doing a design aimed for performance, utilizing better algorithms to reduce resources spent.
Good thing programmers are now encouraged to think even less about that. "Oh, the compiler will probably optimize that away, and it's more readable like this."
Well, looking at the popularity of browsers:
1 - Microsoft Internet explorer > 50%
Have no outspoken plans of supporting anyways. So according to the arguments of the parent, W3C should remove alltogether.
2 - Mozilla Firefox 20-30 %
Strongly suggests implementing Theora, since h.264 is a real indisputable impossibility due to the licensing part.
3 - Apple Safari ~3-8 %
Says they do not want to implement Theora due to fears of patent trolls, pushing H264.
4 - Google Chrome ~2 % (note, is rising the fastest of all right now)
Will support both.
Conclusion; according to parent, either the tag should be dropped since the biggest browser vendor won't implement it. If there is nothing mandated, then content vendors will probably go on with flash (maybe that's the case anyways). In either case a specification cannot JUST implode to the least common denominator that happens to be already implemented, or progress will only continue to happen in proprietary-land, not the land of fair competition.
Ergmh.. and "I wrote ghz" should be "I wrote 2 ghz". You know it's time to sleep when you have to correct the correction.
Actually, I wrote ghz first, but realized (when I was done with the entire post) I were a couple of years behind so doubled everything to more easily adjust stuff. ;)
Also 4ghz != 4 million instructions/second, which is a typo (clarified below).
In other words; two errors in one sentence. Can only be accomplished while watching the sun rise after not sleeping for a night. ;)
Basically, it says how long it would take to be sure to crack it.
To give a comparison, most machines on the net today is clocked at ~4Ghz, that is 4 000 000 000 instructions per second. Imagine a CPU:s doped for only one thing, and one cpu-cycle would mean one key tested ( in reality, there's more like maybe 1000s of cycles/test or something like that ). That would mean that the cpu crunched 172 000 billions of tests per day. With that monster cpu, it would still take 5 billions of billion years to be sure to crunch that encryption.
Even if you filled the theoretical limits of todays internet (unfortunately, IPv6 is still the internet of tomorrow) with these monster machines, it would still take 1,25 billon years to be sure to find the key. This all is of course just theory. Who knows, if you're lucky you may get it in a tenth of that time, only 125 million years. ;)
As a footnote, for the cost of those monster-machines, the operational cost of them and the staff to support them, you'd be much better off bying an army. Physical security in most places is much weaker than AES currently, so it would be much easier just to force the secrets out.
Disclaimer: All this assumes turing-machines, where only one solution at a time can be evaluated. In a quantum-processor, you could theoretically do much better.
Actually, that gives me an idea. Couldn't anyone write a modification to adblock that does this automatically? Basically, you enter a whitelist of companies you want to punish, and whenever adblock sees what looks like one of their ads, it simulates a click in the background, that you're not forced to see?
Encourage a few users to install, and it would start getting noticable. :) While I truly believe ads as such are good for the web as a whole, some ads and ad-driven sites (especially all things Flash) should be punished for ruining my user-experience with blinking crap getting all in the way all the time, even sometimes intentionally trying to trick the user into clicking the wrong links.
Good security involves locking out the user after a certain number of attempts in order to stop a "dictionary attack". I just had to reset a users PW twice this afternoon because she locked herself out of her account. Sure, it's extra hassle but the security is worth it.
That's probably due to poor configuration of the security-measures. You should enforce reasonable passwords being used (the usual, at least 8 characters, with at least 1 character being a digit.) Given that, it will likely take at least 100s of attempts for an attacker, which means you should be safe allowing some 15-20 attemps from the user, which very few users actually would use up before asking for a replacement password.
If the user still fails with those attempts, maybe giving him/her a blank password is the best option, since any security is obviously too unusable for him/her anyways.
I was tired, in a hurry, and I didn't get the HTML-formatting, or the plain-text-mode to respect my paragraphs (which, trust me, a LOT less readable than the monospace-stuff). :)
About the theora not following bitrate, yeah, I discovered that too, a minute after posting this. *fail*
Still though, if you want to compare codecs, you've got to ensure the codecs are run under similar conditions (GOP-size, number of passes, etc.). Driving them in different pipelines (ffmpeg, with tuned x264 as compared to ffmpeg2theora) is far from ideal in that respect.
I work for a television distributor, and half a year ago, we had a customer complaining that we were encoding our MPEG-4-streams with too high bitrate, claiming that other encoders could achieve the same quality at only half the peak bitrate. After investigation, we discovered that he had run the other encoder with 15-second GOP, which in broadcast would infer up to 15 seconds zap-time (time to get a picture when zapping to a channel). So those parameters really do matter for encoder performance, but they are still not always desirable to tune to maximum.
Wow, I just had to comment on this. The article itself is of course nice and intriguing (and the video-clip chosen is an excellent clip to give the codec a hard-time. The grass, and medium-mask net in the background, wow.)
The problem with the article is that it really compares pears with apples, and is not too specific about what pears and what apples. The main problem here is that is uses different suites for conversion, in one hand ffmpeg with some probably well-tuned defaults for x264 (-vpre hq), and on the other hand ffmpeg2theora, that may be tuned for different defaults and different coding-settings. Especially, there are two parameters not covered by the article that may have a huge impact. Multipass-encoding, and keyframe-density.
Multipass-encoding is a technique where you let the encoder skim the content several times, gatherings statistics on progressive levels. Multipass encoding has huge benefits, and can sometimes cut the mbit/quality in half, or more.
Keyframes are special frames in the video-stream where the content can be synced. Between those frames only progressive frames happen, so you can't skip to those frames. Keyframes usually take up a lot more space than the frames in between so you want as few as possible of those, but if you make them too few, you will be limiting seeking severly, and for live content, the zap-time will increase.
Then there's the issues of whether different processing filters were used between the sets, and of course exactly WHICH versions of the codecs were used. "June-something" isn't really a good spec.
To make it a bit more equal comparison, and also with known versions, I tried redoing it myself, using a gstreamer-pipeline and the same source-material used in the article. The pipelines used were:
gst-launch-0.10 filesrc location=soccer_4cif.y4m ! decodebin ! x264enc bitrate=1000 ! avimux ! filesink location=soccer_4cif.y4m.avi
gst-launch-0.10 filesrc location=soccer_4cif.y4m ! decodebin ! theoraenc bitrate=1000 ! oggmux ! filesink location=soccer_4cif.y4m.ogv
Unfortunately, I don't have much time, or hosting space to share the encoded results, but trust me, it was NOT in favor of x264 with these settings. On the bright side, you can try it out for yourself, and fiddle with different settings, all versions are directly from updated Ubuntu Jaunty repositories, as of today. Just install gst-tools, and all gst-plugins even from multiverse.
Happy encoding!
The question is often made to be about whether the artist rights should be respected or not. That is just sad, I really think and hope that all but a minority actually would agree that naturally, creators should be respected and paid.
The real question is, exactly what rights should be held by the creator, and should the distribution-chain out to the customer be controlled somehow?
I.E.
* Is it really realistic to be able to retain rights for a creative work 20-70 years after the actual work was done?
? In the case of patents, how does this affect the market as a whole?
* Should distributors be required to warn about certain potential problems with their distribution methods, such as DRM-servers going offline, or your audio-cd discretely replacing an important piece of your driver-subsystem when you try to listen to some music.
* Many countries have some sort of defined "fair use" for creative works, but what exactly does that constitute?
? Can I lend a copy to a _real physical_ friend?
? What if the friend is a loose aquaintance on the net?
? Can I play it in class, or in a closed socitey, like an interest-club or similar?
? Am I allowed to record live broadcasts and watch later?
Many of these questions are getting waay too little attention today, so I'm glad the increased popularity of the pirate-party gives a big incentive for other parties to start caring.
Oh, and then I suppose there's nothing else. So, you're probably right, why care that almost 8% of all voters in a small offside country thinks that the privacy/copyright/IP questions are more important than all other questions combined (you know, stuff like clean air, working agriculture and maybe some sort of healthcare).
I'm sure it'll rub off on nobody.
The Pirate Party is nothing more than a bunch of college kids who want shit for free.
Interesting. Looking at their top 10 candidates for national government a few years back, you'll find that their average age is 38, and that 7/10 is 40 or older.
Among their top active public members, can be found an author, a musician, several with years of background in it consulting, one with a former background as director of a book publishing company, one with a background in national politics and a few with active backgrounds in other larger political parties.
So while some of the members are certainly cheap greedy kids as you describe them, clearly that does not constitute the entire party.