All the video I generate comes out of my devices in h.264. h.264 uses less bandwidth and is already available on mobile devices. There is a winner this time around and it is h.264. The ship has sailed. Writing something to compete (somewhat) with h.264 is a waste of time and will not get market share. An alternative needs to be better; developers should be writing to compete with the next standard after h.264.
You missed the "already entrenched" bit. Everyone already has h.264. Being "free" doesn't matter, as people already have a superior alternative that they are using (to decode) for free.
Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. It’s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.
If google was confident they were in the clear, they wouldn't be stuffing clauses in the license to the effect of "if this code infringes, you're on your own!".
They can, if they use the system codec. I would be willing to bet that the vast majority of platforms that do not "officially" support h.264 have a CODEC installed that contains support. Either that or the end user does not watch video, and thus is not in the video watching demographic.
Refusing to use the system codecs is retarded. Why should I have multiple copies of CODEC code installed that all need patching and updating, all take space, etc? Why don't mozilla write their own operating system platform while they're at it?
Cute twist you're trying to pull -- make a realistic statement mixed with falsehood. WebM is Open Source, h.264 is proprietary. Both are 'free' to use but there's much, much more likelihood that at any point in the future h.264 could implement 'fees'. Or maybe you're just naive and inadvertently mixing 'open' with 'free'.
Actually, h.264 is "openly" patent encumbered, with a well known licensing policy. WebM/VP8 is on shaky legal ground; there is only google claiming it is "open" and "free". It has yet to be tested in court, and an analysis of the code/algorithm shows siginificant similarities.
Being technically worse, when trying to win customers from a competitor which is already entrenched counts for everything. Really, other than pie in the sky idealism, there is zero reason to use WebM/VP8 - the content generation tools aren't there, inbuilt operating system/device support isn't there, and the CODEC itself is inferior. Other than for political reasons - which the average user has ZERO care for, it is lose-lose-lose. Thus, the average user won't use it.
If you want to win customers over, build something BETTER, not some half-assed attempt that has no hardware or commercial software support and due to inferior performance, never will do.
Exactly. I'm trying to sort out istgt on FreeBSD at the moment, and the documentation is uh..... sparse, to say the least.
If something was hard to get working, write a howto for it. A. it will help you remember how to do it 18 months down the track, and B. you'll help fix the lack of documentation problem that made it hard to get working in the first place.
As I said it won't be easy, but an "insecure" code audit tool isn't itself being directly attacked, it merely needs to generate data for function testing and validate results.
So long as we can capture the process of what a code audit is looking for and how, a program can scan through code far faster than a human, and is far less likely to mis-read characters that look similar, overlook punctuation that alters the functionality of code, etc.
Defining *what* to look for in code is (I suspect) the tricky part.
...which means, we need to make automated code analysis tools better. If humans can't write secure code, then the compiler shouldn't trust that they write secure code. We need tools to evaluate those edge cases and automatically test functions against "unexpected" data to verify whether or not they will *always* behave as expected.
I mean there are already compiler warnings that catch a lot of "dodgy" coding habits, unfortunately a lot of people just turn them off and carry on.
I'm not saying this is an easy task, but history has proven, as suggest above, that humans can't reliably write secure code. Certain humans can audit code, and may catch a lot of bugs. But humans are slow and prone to mistakes.
You forgot the essential aspect: have backups. At some point, it is likely that if you have valuable data, you may well be hacked, irrespective of whatever precautions you have taken. Humans are fallible, and sooner or later someone is going to put a trojan out there that will fool you, and you will get owned.
Make sure you have backups (so you can recover) and that any confidential data is encrypted (to minimize likelihood of stolen data being used against you).
Having AV installed is missing the point. AV is like an airbag in your car. If your brakes fail and you have an accident, it limits damage to you.
The point of pwn2own is to find vulnerabilities in the browser. i.e., in the above scenario, you could compare it to making sure the brakes work on your car. AV definitions are never 100% up to date - the whole notion of a "0-day" exploit is that it hasn't been published, hence the AV defs will likely not catch it. If the browser was secure in the first place, AV would be irrelevant - no exploitable code = no exploit.
The pwn2own guys aren't intending for this to be a "look how easily we can hack most users" thing - its more of a demonstration of how software can be broken, so that the root cause of the security problem (shitty exploitable applications) can be fixed.
If you head over to the macrumors (or other mac) forums, you'll find that plenty of apple "fanbois" are some of the most demanding, critical users around.
Far from "everything apple makes is perfect", there has been much gnashing of teeth over recent iOS updates, Lion, Apple dropping support for older macs on Mountain Lion, etc, etc.
So why are the twin towers the first buildings in history to fall down that were struck by airliners? They were by no means the first airliners to crash into tall buildings.
And thats the point. Why should derived work have limitations placed on the owner of the derived works? It stifles the ability of people to take well tested code and build commercial applications with it. Contrary to GPL zealot indoctrination, not ALL software will be developed for free. BSD people get this, and would rather that commercial software use well tested, robust code for the parts of the software that are non-industry specific, and spend their time focused writing on software that DOESN'T already exist.
What they learn today will be mostly applicable tomorrow, and the unix way of thinking learned will help with other Unixes. As opposed to the NIH flavour of the month thinking of the average Linux distribution. If it has to be Linux, go with slackware, as that is the closeted to the traditional Unix way of doing things.
Agreed with this. If you want to teach people how the OS works, use slackware. If you want to simply enable people to get work done on something other than Windows, one of the user friendlier distributions would be a better choice. However they will make learning how things work more complicated, due to the more complex init scripts, dependencies, etc.
The original code released is still free for anyone to do anything with. Derived works are not free, that is up to the author of the derived works. Even if they close THEIR works, the originals they leverage are still available for others.
Slashdot Mirror
lol. I love slashdot. "i disagree" = mod down flamebait.
All the video I generate comes out of my devices in h.264. h.264 uses less bandwidth and is already available on mobile devices. There is a winner this time around and it is h.264. The ship has sailed. Writing something to compete (somewhat) with h.264 is a waste of time and will not get market share. An alternative needs to be better; developers should be writing to compete with the next standard after h.264.
You missed the "already entrenched" bit. Everyone already has h.264. Being "free" doesn't matter, as people already have a superior alternative that they are using (to decode) for free.
Well that sounds like "head in the sand" to me. From someone qualified who has analyzed the code in detail:
If google was confident they were in the clear, they wouldn't be stuffing clauses in the license to the effect of "if this code infringes, you're on your own!".
But firefox doesn't work great on it, as it doesn't support h.264.
I would bet dollars to donuts that 85% plus of Windows XP installations in 2012 have h.264 codecs installed. Those who don't, don't watch video.
So, webM/vp8 has been tested in court and found to not infringe on anyone else's patents then? Thought not...
They can, if they use the system codec. I would be willing to bet that the vast majority of platforms that do not "officially" support h.264 have a CODEC installed that contains support. Either that or the end user does not watch video, and thus is not in the video watching demographic.
Refusing to use the system codecs is retarded. Why should I have multiple copies of CODEC code installed that all need patching and updating, all take space, etc? Why don't mozilla write their own operating system platform while they're at it?
Actually, h.264 is "openly" patent encumbered, with a well known licensing policy. WebM/VP8 is on shaky legal ground; there is only google claiming it is "open" and "free". It has yet to be tested in court, and an analysis of the code/algorithm shows siginificant similarities.
Being technically worse, when trying to win customers from a competitor which is already entrenched counts for everything. Really, other than pie in the sky idealism, there is zero reason to use WebM/VP8 - the content generation tools aren't there, inbuilt operating system/device support isn't there, and the CODEC itself is inferior. Other than for political reasons - which the average user has ZERO care for, it is lose-lose-lose. Thus, the average user won't use it.
If you want to win customers over, build something BETTER, not some half-assed attempt that has no hardware or commercial software support and due to inferior performance, never will do.
Exactly. I'm trying to sort out istgt on FreeBSD at the moment, and the documentation is uh..... sparse, to say the least.
If something was hard to get working, write a howto for it. A. it will help you remember how to do it 18 months down the track, and B. you'll help fix the lack of documentation problem that made it hard to get working in the first place.
As I said it won't be easy, but an "insecure" code audit tool isn't itself being directly attacked, it merely needs to generate data for function testing and validate results.
So long as we can capture the process of what a code audit is looking for and how, a program can scan through code far faster than a human, and is far less likely to mis-read characters that look similar, overlook punctuation that alters the functionality of code, etc.
Defining *what* to look for in code is (I suspect) the tricky part.
I mean there are already compiler warnings that catch a lot of "dodgy" coding habits, unfortunately a lot of people just turn them off and carry on.
I'm not saying this is an easy task, but history has proven, as suggest above, that humans can't reliably write secure code. Certain humans can audit code, and may catch a lot of bugs. But humans are slow and prone to mistakes.
You forgot the essential aspect: have backups. At some point, it is likely that if you have valuable data, you may well be hacked, irrespective of whatever precautions you have taken. Humans are fallible, and sooner or later someone is going to put a trojan out there that will fool you, and you will get owned.
Make sure you have backups (so you can recover) and that any confidential data is encrypted (to minimize likelihood of stolen data being used against you).
Having AV installed is missing the point. AV is like an airbag in your car. If your brakes fail and you have an accident, it limits damage to you.
The point of pwn2own is to find vulnerabilities in the browser. i.e., in the above scenario, you could compare it to making sure the brakes work on your car. AV definitions are never 100% up to date - the whole notion of a "0-day" exploit is that it hasn't been published, hence the AV defs will likely not catch it. If the browser was secure in the first place, AV would be irrelevant - no exploitable code = no exploit.
The pwn2own guys aren't intending for this to be a "look how easily we can hack most users" thing - its more of a demonstration of how software can be broken, so that the root cause of the security problem (shitty exploitable applications) can be fixed.
If you head over to the macrumors (or other mac) forums, you'll find that plenty of apple "fanbois" are some of the most demanding, critical users around.
Far from "everything apple makes is perfect", there has been much gnashing of teeth over recent iOS updates, Lion, Apple dropping support for older macs on Mountain Lion, etc, etc.
So why are the twin towers the first buildings in history to fall down that were struck by airliners? They were by no means the first airliners to crash into tall buildings.
To be fair, it wouldn't be the first "false flag" op the US has done by a long shot.
And thats the point. Why should derived work have limitations placed on the owner of the derived works? It stifles the ability of people to take well tested code and build commercial applications with it. Contrary to GPL zealot indoctrination, not ALL software will be developed for free. BSD people get this, and would rather that commercial software use well tested, robust code for the parts of the software that are non-industry specific, and spend their time focused writing on software that DOESN'T already exist.
Or even better, i forgot to mention PC-BSD. You can even install FreeBSD from it, but it has full hardware detection, etc.
What they learn today will be mostly applicable tomorrow, and the unix way of thinking learned will help with other Unixes. As opposed to the NIH flavour of the month thinking of the average Linux distribution. If it has to be Linux, go with slackware, as that is the closeted to the traditional Unix way of doing things.
Because out of the above listed tools, at least most of them are crap.
Agreed with this. If you want to teach people how the OS works, use slackware. If you want to simply enable people to get work done on something other than Windows, one of the user friendlier distributions would be a better choice. However they will make learning how things work more complicated, due to the more complex init scripts, dependencies, etc.
The original code released is still free for anyone to do anything with. Derived works are not free, that is up to the author of the derived works. Even if they close THEIR works, the originals they leverage are still available for others.
Maybe it will catch up to the Sandy Bridge Core i5 now?