Read more.Quote:
Following accusations of several GPL violations, Compro Technology has opted to remove certain drivers from its website and promises to adhere to the GPL.
Printable View
Read more.Quote:
Following accusations of several GPL violations, Compro Technology has opted to remove certain drivers from its website and promises to adhere to the GPL.
this is excellent news for all concerned, and i'm including Compro in that. they've also responded pretty quickly compared to how long some GPL violation cases drag on for, so that can only be a good thing
for the people who work hard on the linux kernel, their work is no longer being distributed in ways that directly conflict with their wishes. and for Compro, it means at worst case they've avoided a messy PR fight with some of the most vocal nerds on the internet
if they go the "proper" route to getting their kit supported, and work with the linuxtv developers to add support "at the source", then Compro's cards can get out-of-the-box support in every single linux distro, rather than only old versions of mandriva and fedora. at which point they can be a name that gets thrown around in linux (and htpc) circles as a company that just works, out of the box, and is a great buy. support for their S300 series (at the very least) isn't a million miles from working anyway, so if they can provide the last few hints needed for full support, then that's a lot of extra work and duplicated effort avoided
lord knows their DVB-S card is the cheapest on the market by a long shot, so out of the box support would be fantastic.
if they can kick it up a gear, then they can try and aim for the next batch of major distros - Debian 5.0 is due in September, and both Fedora 10 and Ubuntu 8.10 in late October.
so, as an interim solution, no support. (not that forcing people to use a pre-compiled kernel is support).
(one of my major hates of modern bsd/linux practices is this pre-compiled nonsense, in my virtaully un-payed days of running quake and half life servers i was sure that simply compiling it targeted for my machine would give a hudge performance boost, thou at the time gcc was a bit poor at this. I'm quite tempted to have a full rant at this, i've got vc6 un-service packed, and vs2008 at work, i'll compile the same simple test app in both, and bench it next time i'm bored, i recon there will be some major boostage to be had by having a compiler that has a clue about my cpu).
The question i have to ask is, why where they needing to provide a whole compiled kernel anyway, linux's driver model isn't *that* bad that they should have to be fiddeling with other modules to leaver in their support, i wounder what they where tweaking?
The problem is thou hex, they won't see it as a chance to get their hardware as an established brand that just works. Relteck for instance spend hudge wads of cash on their drivers, they've noticed that for the vast majority of users, even a few who play games, everyones waxing lyrical about how great their products are under vista, how it just works, whilst 3 years ago they where considered an economy choice, they're now seen as solid and reliable, just from better drivers. Many companies as such want to sit on their work, and not allow others to get their competative edge, even thou its damaging to the CS world.
well, indeed. an insecure kernel for mandrake 2007.1 is hardly "support"Quote:
Originally Posted by TheAnimus
for most apps, there's little benefit to compiler-side optimizations done by a "generic" compiler. use a CPU-specific one like ICC or PathCC, and you get a boost. and if it's performance critical, pull out the assembly & do runtime cpu detection (like mencoder does)Quote:
(one of my major hates of modern bsd/linux practices is this pre-compiled nonsense, in my virtaully un-payed days of running quake and half life servers i was sure that simply compiling it targeted for my machine would give a hudge performance boost, thou at the time gcc was a bit poor at this. I'm quite tempted to have a full rant at this, i've got vc6 un-service packed, and vs2008 at work, i'll compile the same simple test app in both, and bench it next time i'm bored, i recon there will be some major boostage to be had by having a compiler that has a clue about my cpu).
our suspicion is that they copy-pasted large portions of (proprietary) code from the Zarlink SDK - and here's the stupid bit, ALL the chips used by their cards have support in the standard upstream kernel. all they had to do was some bugfixing to a couple of files (e.g. mt352.c) to fix card-specific problemsQuote:
The question i have to ask is, why where they needing to provide a whole compiled kernel anyway, linux's driver model isn't *that* bad that they should have to be fiddeling with other modules to leaver in their support, i wounder what they where tweaking?
the other option is simple ignorance of correct linuxy practices - any bugger can write a kernel module, any bugger can edit a .c file, perhaps their dev's desktop just happened to have mandrake on it
realtek? they already do just that though - their chips tend to just work out of the box on linux, and you can download some source straight from RealtekQuote:
The problem is thou hex, they won't see it as a chance to get their hardware as an established brand that just works. Relteck for instance spend hudge wads of cash on their drivers, they've noticed that for the vast majority of users, even a few who play games, everyones waxing lyrical about how great their products are under vista, how it just works, whilst 3 years ago they where considered an economy choice, they're now seen as solid and reliable, just from better drivers. Many companies as such want to sit on their work, and not allow others to get their competative edge, even thou its damaging to the CS world.
they've got their fingerprints all over the kernel. in the sound case, Kailang Yang and PeiSen Hou at realtek are their main contributors
In my C++ days (which where spent bitching about much nicer java was) i was amazed when the HL mod i was working got a 5% frame rate boost just with a simple update to visual studio (which included the ms c compiler update). No code changes, no config changes. This was running intel cpus.
as for ignorance of practices? I don't see that for a second, when i last tried to write a kernel module, it was following about 4 HOWTOs (that didn't quite cover it properly) and took me a bloody week to do something i did with an MS tool for NT5! I can't see them been ignorant.
Someone as you suggest did something naughty and tried to hide it is one likely option, the other been they just didn't want to share and enjoy.
Gcc can do some rather nice sub-architecture optimisations these days, their value varies between programmes of course.