Huh? They don't have to tell you they're using Linux either. That's why people make noise every now and then when a company is discovered to be using Linux in its embedded product without providing the source as required by the license. Not every case like this is going to be noticed by anybody, because you have to have some insight into the system (such as recognizing the mplayer strings in the binary, or a TCP fingerprint, or something) in order to even devise a theory as to the OS it's running (Linux, BSD, whatever).
If Linux was on the desktop of everyone's grandmother, unpatched and unfirewalls, it would also be hacked in a jiffy.
Do you have any idea how stupid this statement is? First of all, such a statement simply assumes that it is not possible to write correct software. That is beyond arrogance and disregards the primary benefit of open source: like solid science, peer review is paramount in ensuring correctness of the results.
Furthermore, if your claim (that popularity of a software package somehow implies or introduces security problems) had any merit, Apache (the majority web server by a huge margin) should have been swiss cheese by now. Yet, somehow the minority IIS web server manages to have a serious remote vulnerability at least every year. How can you claim in good faith that popularity is what causes bad software, as opposed to e.g. proprietary development, or Microsoft?
Oh, please do elaborate on these security flaws that are "inherent" to Linux. I can't wait for your response! With all these inherent Linux flaws, I might have to load another operating system until Linux is redesigned.
Oh? Most Linux distributions have out-of-the-box remote vulnerabilities? Please do elaborate. I'd like to close those holes on my machines. I wonder why I haven't been exploited yet, since our firewall only blocks SMB traffic.
There are no more open source manufacturers. That's why Open Graphics is the last resort for anyone who cares about transparency and freedom in graphics hardware.
Oh, spare me the trite retorts. You seem to have a problem reading like the grandparent.
I specifically mentioned that the reason we don't see any docs, boils down to that the companies don't see enough value in open source development in order to justify the costs involved in being helpful - that includes the cost, in whatever form, of providing documentation, be it in the form of revealed trade secrets and lost competitive advantage, or a patent suit.
Trade secrets are rarely an issue because the market is defined by 6 month product cycles and engineers flow back and forth between companies. Any innovative new idea will either be reverse engineered or patented. Most of the time, it's patented, because patents are cheap and easy to obtain these days. If a feature is patented, the company could freely release documentation and be safe from cloning. However, they still don't release documentation, and the reason why is because _they_ may be infringing any number of an unknown competitor's patents at any given time, and the last thing any company wants to do is invite legal problems. The inevitable outcome of such a battle is cross-licensing, which dilutes the value of the held patents.
The end result is that the best any company will do these days is to provide docs under NDA after a background check. This way, they are protected from secrets being handed over to a competitor indiscriminately, and also from others discovering that their patents are being violated. Unfortunately, for some companies, the risk is too great compared to the benefit to even justify an NDA policy. This stance is the most common in the industry today, and is the natural result of a system where frivolous litigation is the norm and where the PTO grants patents willy-nilly to anyone who asks.
I would highly recommend making the DRM modular while you get things working. Don't forget agpgart either. Does it work with the _stock_ Debian kernel in sid? Can you post your/var/log/XFree86.0.log?
It seems that you can't read, or are deliberately missing the point. Nobody except the most extreme of extremists are calling for them to release their driver source code. What we (developers) want is documentation sufficient to develop our own free drivers that are unencumbered by third-party IP and corporate licensing concerns.
Unfortunately, the manufacturers obviously don't see enough value in open source drivers to offset the risk of patent suits and/or cloning of their special hardware features. It's a matter of perspective - we see no legitimate reason why they should not release their internal documentation to interested/qualified open source developers, but they probably see themselves sunk if they did. After all, look what happened to the trailblazers in open source graphics docs: 3Dfx, Matrox, 3DLabs, etc.
The only solution for people who value open source drivers is to stop buying their products and develop our own to compete with them. Relentless lobbying will only waste their time and make them less likely to deal with folks in the open source community.
For people who don't care about open source drivers as long as a binary driver works good enough for you, just go ahead and buy a card from the leading manufacturers. But don't blame Linux when the driver blows up or acts strangely. As long as these vendors refuse to cooperate with the open source development model, the onus is on them to go the extra mile and produce a stable product that interoperates with the open source world.
So far, they haven't done well at that challenge, suggesting that either open source developers are deliberately foiling them (some people believe the absence of a driver abstraction layer falls along these lines), they employ incompetent programmers, or they are simply not providing their best effort as a company towards Linux support. I suspect the latter, and only market share will change that. (Hence the driving force behind platform advocacy, as opposed to the 'zealot' label that platform advocates receive from neophytes who misunderstand or reject the fundamental correlation between platform market share and quality of vendor support)
Have you tried upgrading your DRM kernel module to something newer? If you are running a bleeding edge DRI, you are probably going to run into trouble unless you keep your kernel module up to date too.
You're wrong. There is no documentation available for anything newer than i810/i815 except under NDA. And for the latest chips, they don't provide docs at all (yet).
What you say is just ridiculous because it hints at the idea that Linux doesn't have remote root exploits, only Windows does, which is just plain wrong.
You are reading a false dichotomy into my statement where there is none. I responded to your post because you were implying that the security risks of running Linux and Windows were equivalent. That is false because the number of remote root vulnerabilities, which are the most damaging vulnerabilities by any measure, are historically far more numerous in Windows than Linux. Furthermore, many of the remote root vulnerabilities that Linux systems have suffered are the fault of shoddy distributors who run services such as Apache as root unnecessarily, when the security architecture of Linux is specifically designed so that service daemons have no reason at all to run as root. Such stupidity turns what should be a 2-level exploit into a 1-level triviality. A reasonable person might blame those specific distributions for their flaws, instead of blaming the open source development model or Linux itself without providing evidence that either is why Linux systems get exploited.
I believe that developers have the right to control their invented software. I don't want to use software *against* the wishes of its creators.
That's nice, but in order for you to enact your idea of moral rights to dictate how the software should be used, you would have to uphold EULAs as valid and enforceable, thus negating first sale rights. Otherwise, the developer has no right to step into my home and say "Sorry, you can't use my software to send e-mail to people I don't like" or "Sorry, you can't use my software to publish damning performance comparisons of my product". Through copyright, they can control how the software is redistributed, but they cannot control how it is used. You can believe all the hogwash you want about moral rights of artists/authors to dictate how their work is to be used by the purchaser, but that's the facts, jack. Of course, *you* can uphold whatever wishes you want as a personal choice. But the law compels no one to obey arbitrary whims regarding use of a product just because its creator said so.
A security hole is a security hole is a security hole.
Wow, so a trivial remote exploit like the NetBIOS or RPC worms is equivalent to a local root exploit, which requires an account on the machine or a secondary compromised service? I think you have perspective issues here.
If I violate the terms of the GPL don't they enforce it the same way companies enforce EULA's? Its the same thing really.
No. One is a contract, the other is a copyright license. Two completely different areas of law. And no, they aren't the same thing. You can't possibly violate a copyright license without copying the software. You can violate a EULA 20 ways just by trying to make use of the software.
You could file a bug on the package to include a default file. Most packages' init scripts source an/etc/default/* script for their settings, which _is_ considered a configuration file and won't be overwritten on upgrades.
Slashdot Mirror
OK, so when was x86-64 incorporated into a stable release? That's all that matters to an end user or developer.
Huh? They don't have to tell you they're using Linux either. That's why people make noise every now and then when a company is discovered to be using Linux in its embedded product without providing the source as required by the license. Not every case like this is going to be noticed by anybody, because you have to have some insight into the system (such as recognizing the mplayer strings in the binary, or a TCP fingerprint, or something) in order to even devise a theory as to the OS it's running (Linux, BSD, whatever).
Yeah. Microsoft released a TCP/IP stack for Win3.1 later on. here is a page that gives you all the info you need.
TSIA. It would probably be a bad idea to start publishing material with it until the patent expires.
Furthermore, if your claim (that popularity of a software package somehow implies or introduces security problems) had any merit, Apache (the majority web server by a huge margin) should have been swiss cheese by now. Yet, somehow the minority IIS web server manages to have a serious remote vulnerability at least every year. How can you claim in good faith that popularity is what causes bad software, as opposed to e.g. proprietary development, or Microsoft?
Oh, please do elaborate on these security flaws that are "inherent" to Linux. I can't wait for your response! With all these inherent Linux flaws, I might have to load another operating system until Linux is redesigned.
Oh? Most Linux distributions have out-of-the-box remote vulnerabilities? Please do elaborate. I'd like to close those holes on my machines. I wonder why I haven't been exploited yet, since our firewall only blocks SMB traffic.
There are no more open source manufacturers. That's why Open Graphics is the last resort for anyone who cares about transparency and freedom in graphics hardware.
I specifically mentioned that the reason we don't see any docs, boils down to that the companies don't see enough value in open source development in order to justify the costs involved in being helpful - that includes the cost, in whatever form, of providing documentation, be it in the form of revealed trade secrets and lost competitive advantage, or a patent suit.
Trade secrets are rarely an issue because the market is defined by 6 month product cycles and engineers flow back and forth between companies. Any innovative new idea will either be reverse engineered or patented. Most of the time, it's patented, because patents are cheap and easy to obtain these days. If a feature is patented, the company could freely release documentation and be safe from cloning. However, they still don't release documentation, and the reason why is because _they_ may be infringing any number of an unknown competitor's patents at any given time, and the last thing any company wants to do is invite legal problems. The inevitable outcome of such a battle is cross-licensing, which dilutes the value of the held patents.
The end result is that the best any company will do these days is to provide docs under NDA after a background check. This way, they are protected from secrets being handed over to a competitor indiscriminately, and also from others discovering that their patents are being violated. Unfortunately, for some companies, the risk is too great compared to the benefit to even justify an NDA policy. This stance is the most common in the industry today, and is the natural result of a system where frivolous litigation is the norm and where the PTO grants patents willy-nilly to anyone who asks.
I would highly recommend making the DRM modular while you get things working. Don't forget agpgart either. Does it work with the _stock_ Debian kernel in sid? Can you post your /var/log/XFree86.0.log?
Unfortunately, the manufacturers obviously don't see enough value in open source drivers to offset the risk of patent suits and/or cloning of their special hardware features. It's a matter of perspective - we see no legitimate reason why they should not release their internal documentation to interested/qualified open source developers, but they probably see themselves sunk if they did. After all, look what happened to the trailblazers in open source graphics docs: 3Dfx, Matrox, 3DLabs, etc.
The only solution for people who value open source drivers is to stop buying their products and develop our own to compete with them. Relentless lobbying will only waste their time and make them less likely to deal with folks in the open source community.
For people who don't care about open source drivers as long as a binary driver works good enough for you, just go ahead and buy a card from the leading manufacturers. But don't blame Linux when the driver blows up or acts strangely. As long as these vendors refuse to cooperate with the open source development model, the onus is on them to go the extra mile and produce a stable product that interoperates with the open source world.
So far, they haven't done well at that challenge, suggesting that either open source developers are deliberately foiling them (some people believe the absence of a driver abstraction layer falls along these lines), they employ incompetent programmers, or they are simply not providing their best effort as a company towards Linux support. I suspect the latter, and only market share will change that. (Hence the driving force behind platform advocacy, as opposed to the 'zealot' label that platform advocates receive from neophytes who misunderstand or reject the fundamental correlation between platform market share and quality of vendor support)
Have you tried upgrading your DRM kernel module to something newer? If you are running a bleeding edge DRI, you are probably going to run into trouble unless you keep your kernel module up to date too.
You're wrong. There is no documentation available for anything newer than i810/i815 except under NDA. And for the latest chips, they don't provide docs at all (yet).
MIPS doesn't. :(
Check your mixer settings (alsamixer). You probably have a few channels or the master volume muted.
So that means they are for abolishing corporations too, since limited liability is a government interference in the market?
The ATI open source driver was developed with NDA documentation. If it weren't for the NDA, it wouldn't exist at all.
This isn't insightful or interesting. Apparently the parent has never heard of NDA contracts.
You could file a bug on the package to include a default file. Most packages' init scripts source an /etc/default/* script for their settings, which _is_ considered a configuration file and won't be overwritten on upgrades.