There were several root exploits as late as 2.6.10. That is a hell of a lot of vulnerable kernels out there. And as soon as another one is found, it starts all over again.
And all you need to do is make your system LSB compliant and then you can install any LSB-compliant package on it.
No. A package needs to be built against the same versions of shared libraries that are on the target system or breakage will occur. This is what leads to vendors having to ship 20 different RPMs for a single application.
How does autopackage handle things like different names and locations for libraries?
Since the distribution provides autopackage itself, I would presume that the distribution packagers would know how to configure autopackage to build packages compatible with the distribution. But I must confess I don't really understand what you are asking.
Not true at all. You are only in hot water if you run the software as root.
We'd like that to be true, but in reality there probably isn't a single version of Linux that is not vulnerable to a root exploit from an unprivileged process. Anyway, you could use trust to decide whether packages signed by this person/company should be able to execute code as root on your machine. It doesn't have to be all or nothing.
So what? RPM and Debian packages both run their pre- and post-installation scripts as root. If you don't trust the software provider, you are in hot water no matter where you stand.
Even (1) is probably a violation of something because the Altera synthesis tools, and their output, are likely licensed only to be used for Altera FPGAs. The customer does not buy the tool, he only buys a license.
So what? Then the customer is the one that should be sued, not ClearLogic; ClearLogic did not violate the EULA or in fact make any agreement at all with Altera. Altera just didn't like the competition, that's all, and decided to run a smaller company into the ground before they could take root.
Autopackage generates distribution-specific packages from generic autopackage'd sources. All you need to do is add support for your distribution/package manager to autopackage in order to be able to install any autopackage'd source on your machine as a native package - it is automatically generated by autopackage.
Heh. Glad to see a mention of Rocky's Boots. I grew up with that program. My name is mentioned in the Underdogs blurb.
I seemed to be the only one in the world with a PC copy. When I emailed Sarinee at first, she insisted that it did not exist for the PC. I made a copy with my venerable Central Point Option Board and sent it to Demonlord for cracking. The crack turned out to be simple.
I was glad to provide this apparently-rare program, because it was the primary facilitator of my being able to grasp digital logic. Absolutely invaluable. And fun to 'boot'.
NT was a solid, compentely-constructed base. Its downfall was design compromises that were driven by management and marketing that ended up corrupting the architecture and producing many of the issues we see today on XP. If Microsoft were to adopt a BSD base (unlikely due to NIH syndrome which is rampant there), what makes you think the same would not happen given time? It is a problem with the company mission and command structure, not with the engineers.
Sorry, I had the VST confused with another format. It does appear that the only problem with the majority of VST plugins is that they are closed-source by their respective authors and that is what necessitates WINE. Hmmm..._______
The VST itself is a closed source program. Yes, you can create one for free using the SDK (at least if you use Windows). And you can implement a VST host, which is exactly what was done and requires WINE to run the VST interpreter inside the plugin. To not require an emulation hack would require enough information to replace the VST interpreter component with an open implementation. That is what will never happen, and why emulation hacks will always be required when dealing with these closed formats. There's really nothing that can be done besides to implement an open virtual instrument format and encourage designers to migrate to it. And users should be aware that this barrier is the fault of the vendors, not the fault of open source developers.
All of the formats you mentioned are kept secret by their respective vendors, some are encrypted, and some are covered by patents. Hell will freeze over before open source software will be able to interoperate with them, and this is a purely ARTIFICIAL limitation imposed by the vendors who create them.
You could call this a failing of open source (that you are unable to use formats from vendors who are hostile to open source). But what would you have us do? Maybe the answer lies in eliminating such vendors as a dependency, but that would take someone else to produce high quality virtual instruments.
Anhydrous ammonia. Like ethanol, the water cannot be removed from ammonia without a drying agent. Grocery store ammonia is comparably useless for making methamphetamine when there is an infinite supply for the taking at any farm co-op.
If you are a Libertarian... Oh, never mind. Large-L Libertarianism is indefensible as anything but a philosophy held by people who don't think very hard.
Uh-huh. Something tells me *you* just can't think hard enough to refute its premises, so you resort instead to insults in order to make yourself more comfortable in that you have made the correct choice of whatever flavor of groupthink you subscribe to.
And if you don't "own" the land, but simply reside on it until your claim to it can no longer be enforced, then upon what moral basis does using force to protect that claim stand? Without recognizing ownership as a natural right, the chain of reasoning behind protecting property quickly goes circular.
Gatto is WRONG. The GPL grants NO rights in the realm of patents to the recipient of the software. Patents can cover even USE of the product for a particular purpose, and this is not something the GPL can address, because otherwise it would become a EULA. All you can encode into the license itself is termination of distribution rights if someone down the line inserts patented code and redistributes it, at which point the patent hostility is transformed into a copyright violation if the company in question continues to distribute the software. They can STILL sue the people they redistributed the software to, unless they licensed their patent to them in the process.
It is quite possible that someone either releases a patented piece of original software, or adds patented code to an existing codebase and redistributes it. The GPL's protection, like any other copyright license, extends only to copying and (re)distribution. Unless it contains language specifically sublicensing all patents on the code to all recipients (and the GPL does NOT), its powers can only terminate the right of someone who does not hold the copyright on the original GPL codebase to redistribute the code. It cannot prevent anyone who already received a copy of the patented code from being sued for continuing to use that copy!
Slashdot Mirror
Oh yeah, because supporting Linux with a proprietary driver is just a walk in the park. Please!
Bluetooth socket exploit
LSM exploit
uselib() exploit
stack growth exploit
So what? RPM and Debian packages both run their pre- and post-installation scripts as root. If you don't trust the software provider, you are in hot water no matter where you stand.
Autopackage generates distribution-specific packages from generic autopackage'd sources. All you need to do is add support for your distribution/package manager to autopackage in order to be able to install any autopackage'd source on your machine as a native package - it is automatically generated by autopackage.
That's why you keep your home directory on a RAID, duh! :)
I seemed to be the only one in the world with a PC copy. When I emailed Sarinee at first, she insisted that it did not exist for the PC. I made a copy with my venerable Central Point Option Board and sent it to Demonlord for cracking. The crack turned out to be simple.
I was glad to provide this apparently-rare program, because it was the primary facilitator of my being able to grasp digital logic. Absolutely invaluable. And fun to 'boot'.
No, you weren't the only one.
NT was a solid, compentely-constructed base. Its downfall was design compromises that were driven by management and marketing that ended up corrupting the architecture and producing many of the issues we see today on XP. If Microsoft were to adopt a BSD base (unlikely due to NIH syndrome which is rampant there), what makes you think the same would not happen given time? It is a problem with the company mission and command structure, not with the engineers.
As for running Quake, I have a P120 laptop which does that just fine. No, not GLQuake, but at 320x240, who cares?
Sorry, I had the VST confused with another format. It does appear that the only problem with the majority of VST plugins is that they are closed-source by their respective authors and that is what necessitates WINE. Hmmm..._______
The VST itself is a closed source program. Yes, you can create one for free using the SDK (at least if you use Windows). And you can implement a VST host, which is exactly what was done and requires WINE to run the VST interpreter inside the plugin. To not require an emulation hack would require enough information to replace the VST interpreter component with an open implementation. That is what will never happen, and why emulation hacks will always be required when dealing with these closed formats. There's really nothing that can be done besides to implement an open virtual instrument format and encourage designers to migrate to it. And users should be aware that this barrier is the fault of the vendors, not the fault of open source developers.
I've had several Xcelite snips break on me, so they are not as synonymous with quality in my mind as with some others here...
Please mod parent up; real world experience in this area is sorely lacking.
You could call this a failing of open source (that you are unable to use formats from vendors who are hostile to open source). But what would you have us do? Maybe the answer lies in eliminating such vendors as a dependency, but that would take someone else to produce high quality virtual instruments.
Why We Fight by Congressman Ron Paul.
Anhydrous ammonia. Like ethanol, the water cannot be removed from ammonia without a drying agent. Grocery store ammonia is comparably useless for making methamphetamine when there is an infinite supply for the taking at any farm co-op.
And if you don't "own" the land, but simply reside on it until your claim to it can no longer be enforced, then upon what moral basis does using force to protect that claim stand? Without recognizing ownership as a natural right, the chain of reasoning behind protecting property quickly goes circular.
They laughed at Edison. They laughed at Einstein. But they also laughed at Bozo the Clown.
It is quite possible that someone either releases a patented piece of original software, or adds patented code to an existing codebase and redistributes it. The GPL's protection, like any other copyright license, extends only to copying and (re)distribution. Unless it contains language specifically sublicensing all patents on the code to all recipients (and the GPL does NOT), its powers can only terminate the right of someone who does not hold the copyright on the original GPL codebase to redistribute the code. It cannot prevent anyone who already received a copy of the patented code from being sued for continuing to use that copy!