Let A be some 3d party software covered by patents that is unrelated to FFMpeg. Let B be Chrome. Let C be FFMpeg. Google got a patent for A. The patent is unrelated to FFMpeg.
No, I don't think so. The patent(s) are for H.264 and H.264 is in FFmpeg, therefore the patents cover FFmpeg.
Let me put it another way. When someone says "we don't care about US law or whether our software is illegal in the US", that's pretty unhelpful to a lot of people.
For branded encoder and decoder products sold both to end users and on an OEM basis for incorporation into personal computers but not part of an operating system, royalties per legal entity are 0 - 100,000 units per year = no royalty; US $0.20 per unit after first 100,000 units each year; above 5 million units per year, royalty = US $0.10 per unit.
So, what you're telling us is that although all of us in the States have been using FFMpeg illegally without a license for years, when someone finally decides to try and be legal and purchase a license, now they are still in the wrong? Sounds like the FFMpeg people need to start dual-licensing or something
Of course, I'm still missing the biggest point here - since when do they need FFMpeg for HTML 5 support? It doesn't require any patented codecs, and they could always use DirectShow filters.
In reality Theora isn't that great and Google probably wants to save bandwidth, so they support H.264. Since XP/Vista includes no H.264 decoder, Google has to ship their own.
VeriSign's rates are regulated by ICANN already so they can only raise prices 7% per year. However, some of us think the prices should be going down, not up.
If you increase 10x each generation you have to wait quite a while between generations. You can also end up in a "Goldilocks" situation where 1 Gbps is not enough but 10 Gbps is overkill and too expensive. 2x or 4x per generation is a lot smoother.
Current SSDs are very close to the SATA 2.0 limit and the performance of flash is about to double thanks to ONFI 2.0, so we can expect SSDs to quickly adopt SATA 3.0.
No, Google bought a fraction of the world's dark fiber. Heck, even if they bought all of it, there are already a ton of competitive backbones. Google is hardly a monopoly in markets other than search and Web ads.
In that case, you should have read the part of the contract (which has always been there) stating that they may change the contract at any time. They probably also have a section stating that if you don't agree to the contract your only choice is to cancel service.
It's unfair to sell and offer the service as "unlimited", which they did years ago when the idea of "unlimited" was big for dial-up companies, and then turn around and tell people they're going to limit them.
Can't we put this to rest? If they advertised their service as unlimited years ago, then they can't change it now? Things change.
I fully anticipate having to explain to a customer why I can't take care of that server problem until next month because my daughter used up our bandwidth allocation on the Playhouse Disney web site.
No, you'll just pay the overage out of your pocket or be fired.
I graduated with a CS bachelors a few years ago thinking I would have a good shot at doing some compiler design or maybe kernel hacking..
This is definitely a teaching failure (or at least disconnect). In my OS/compiler classes, they said "you're probably never going to work on these things in your career, but you need to know how the OS/compiler works so that you can use it properly".
Slashdot Mirror
Let A be some 3d party software covered by patents that is unrelated to FFMpeg. Let B be Chrome. Let C be FFMpeg. Google got a patent for A. The patent is unrelated to FFMpeg.
No, I don't think so. The patent(s) are for H.264 and H.264 is in FFmpeg, therefore the patents cover FFmpeg.
Oddly, the license for the V8 assembler is listed as Copyright (c) 1994-2006 Sun Microsystems Inc. WTF?
V8 author Lars Bak used to work for Sun, so maybe he borrowed something.
Let me put it another way. When someone says "we don't care about US law or whether our software is illegal in the US", that's pretty unhelpful to a lot of people.
The patent license permits royalty-free redistribution of the Library
I doubt that.
For branded encoder and decoder products sold both to end users and on an OEM basis for incorporation into personal computers but not part of an operating system, royalties per legal entity are 0 - 100,000 units per year = no royalty; US $0.20 per unit after first 100,000 units each year; above 5 million units per year, royalty = US $0.10 per unit.
So, what you're telling us is that although all of us in the States have been using FFMpeg illegally without a license for years, when someone finally decides to try and be legal and purchase a license, now they are still in the wrong? Sounds like the FFMpeg people need to start dual-licensing or something
Exactly. Unfortunately, they'll probably just say "we don't care about patents" which doesn't help anyone.
Of course, I'm still missing the biggest point here - since when do they need FFMpeg for HTML 5 support? It doesn't require any patented codecs, and they could always use DirectShow filters.
In reality Theora isn't that great and Google probably wants to save bandwidth, so they support H.264. Since XP/Vista includes no H.264 decoder, Google has to ship their own.
Nope, you've got it wrong. Chrome includes ffmpeg.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020035.html
VeriSign's rates are regulated by ICANN already so they can only raise prices 7% per year. However, some of us think the prices should be going down, not up.
Yeah, we're sure. HP servers don't have the Nuova memory expander ASIC.
SANs typically provide reliable, shared storage; PCI cards don't.
If you increase 10x each generation you have to wait quite a while between generations. You can also end up in a "Goldilocks" situation where 1 Gbps is not enough but 10 Gbps is overkill and too expensive. 2x or 4x per generation is a lot smoother.
Current SSDs are very close to the SATA 2.0 limit and the performance of flash is about to double thanks to ONFI 2.0, so we can expect SSDs to quickly adopt SATA 3.0.
No, because SAS will always be more expensive than SATA.
No, Google bought a fraction of the world's dark fiber. Heck, even if they bought all of it, there are already a ton of competitive backbones. Google is hardly a monopoly in markets other than search and Web ads.
This type of image processing requires obscene amounts of memory and CPU time to do.
That's OK; have you heard of Winmodems? Just imagine a cheap scanner that does all the correction in software on your PC.
If there's no way to convince people to give up "dark" address space then it doesn't matter.
Not any more. But if you can steal their revenue without having to do much work, who cares if they're profitable?
In that case, you should have read the part of the contract (which has always been there) stating that they may change the contract at any time. They probably also have a section stating that if you don't agree to the contract your only choice is to cancel service.
It's unfair to sell and offer the service as "unlimited", which they did years ago when the idea of "unlimited" was big for dial-up companies, and then turn around and tell people they're going to limit them.
Can't we put this to rest? If they advertised their service as unlimited years ago, then they can't change it now? Things change.
I fully anticipate having to explain to a customer why I can't take care of that server problem until next month because my daughter used up our bandwidth allocation on the Playhouse Disney web site.
No, you'll just pay the overage out of your pocket or be fired.
According to the thread, many people in OSI believe that MIT/BSD licenses do (implicitly) grant patent rights. This was a surprise to me.
whether the TRIM command work through a RAID controller and actually reach the SSD?
Probably not. RAID controllers will need new firmware.
I graduated with a CS bachelors a few years ago thinking I would have a good shot at doing some compiler design or maybe kernel hacking..
This is definitely a teaching failure (or at least disconnect). In my OS/compiler classes, they said "you're probably never going to work on these things in your career, but you need to know how the OS/compiler works so that you can use it properly".
Running x86 emulation on zArch is going to be slooooow.
Interpreters are not dangerous and are no more difficult to analyze than regular code. IIRC someone compiled Python for NaCl and it works.
Fortunately, Win32 binaries (like NaCl) still run on 64-bit Windows.