Just changing the root password is not enough, this 'bug' was here for months any could have installed a rootkit or did who knows what. This is going to be a fresh install for me.
The password is only available to someone with local access to the system. If your system only has one account (like mine), someone would only be able to read the password if they knew it already.
This vulnerability is serious for computer lab setups, but it's irrelevant for home users that aren't running any remotely accessibly services.
Firstly, it's probably best if you think of FC, Mandriva, SuSE, etc each as separate OSs, even though they share a kernel and many components. Secondly, if you must, build a statically-linked binary. That's often what the commercial vendors do for their 'officially supported' binaries. Alternatively, there are various distro-neutral packaging solutions that might be werth looking into, e.g. AutoPackage [autopackage.org].
And that, right there, is the crux of the issue: Ubuntu, Fedora Core, Mandriva, SuSE, Gentoo, Debian, Slackware,... (and hundreds more at distrowatch.com) are all seperate operating systems. I'm well aware that that is the state of things now. What I'm trying to say is, it doesn't have to be that way.
Statically linking (or the equivalent: packaging your own dynamically linked libraries and using those) is an acceptable solution, provided it's used on programs without too many dependencies, and only used on a small scale. Otherwise, the system's memory usage will increase dramatically and performance will go down. The downloadable Linux versions of Firefox and OpenOffice.org take this approach. It works for them because they reimplement almost everything (including their UIs) as internal libraries. They're both genetically related to formerly proprietary codebases, and therefore they don't represent typical Linux programs.
I've been following Autopackage for a long time. It's got a lot of potential. I hope they can work out the kinks, and get a larger body of software packaged, so I can get new software releases without worring about someone packaging it for my distribution. Another interesting project along similar lines is Klik.
That's a ridiculous solution. Why should every distribution be responsible for building a binary package for every Free Software program that's out there, and updating them every release? Sounds like a huge scalability problem to me.
This is *not* a hypothetical problem. One project I follow is Battle for Wesnoth, a cool GPL-ed turn based strategy game. They release new versions, in source tarball form, quite frequenty. Typically, the Windows and MacOS X binaries come out within a day or two of release. And the GNU/Linux binaries? The most recent user submitted version might be several versions out of date. The distribution packaged versions are even more out of date that the user submitted ones. For a fast paced project like Wesnoth, being out of date is bad. (I resort to building from source, because I know exactly which libraries I need, but some distros don't package libSDL-dev, ugh)
Also, I'm not holding FOSS to a "higher" standard. Every other operating system out there besides GNU/Linux *has* a definative baseline you can build applications against, without requiring every application to be integrated into the OS. GNU/Linux is unique in that it has multiple incompatible baselines. If I wanted to release a cool new GPLed application right now I'd have no way of releasing a common binary package that would work for all of my users. There are too many incompatible build environments.
By the way, my previous post wasn't meant as a criticism of FOSS. As a GNU/Linux user, I really want to see this problem solved:)
Lets take an open source program, which we'll call program X. Program X's developers happily continue adding cool new features and releasing out new versions. The problem is, the only way for GNU/Linux users to get program X is 1) build it from source, or 2) hope someone has built a binary for their distribution. Option #1 is time consuming, and tracking down build dependencies is difficult and error prone. Which leaves us with option #2, the current state of GNU/Linux distributions.
Binary compatibility, or lack thereof, is why the current fragmentation of desktop Linux distributions is so irritating. My #1 criteria for using a distribution is that it has best selection of software. Currently, I'm using Ubuntu because it's Debian with a commitment to a 6-month release cycle.
I've thought a lot about the distribution incompatiblity problem, because it really hurts my desktop GNU/Linux experience. It's not the Linux kernel, which has excellent binary compatibility with userspace. It all boils down to poor package and version management, especially with respect to shared libraries.
The first problem: there's no technical reason why you can't have multiple versions of the same shared library (in fact, that's what the/lib library naming scheme is for). But most distributions have package managers that enforce only one version per libary. Example: KDE in Debian testing/unstable breaks horribly when a new version of kdelibs comes out. Typically, half of the kde packages depend on the old version (because they haven't propegated to unstable yet or were kicked out of testing), so "apt-get update" will happily uninstall half of KDE! The package manager is enforcing an unnecessary constraint. Why can't I have multiple versions of a shared library package installed?
The other reason for distibution incompatibility is the packages themselves. There are a few different (incompatible) package formats and much worse, each distribution uses its own (incompatible) package naming scheme. Thus, I might have a package build for Fedora Core that depends on libsdl-ttf (Simple DirectMedia Layer True Type Font library), but who knows how it will be packaged or what it will be named in any given distribution?
So, it's the damned package format, package naming, and dumb handing of shared libraries that's to blame. What's the solution? Well, I think the answer is technically simple, but complex to implement. 1) package managers that are smarter about shared libraries, 2) standard package naming scheme, and 3) someone, either library developers or a standards body, needs to build "official" versions of each libary release. This would give GNU/Linux application developers a common "SDK" so they can build their application independently of their distribution.
The market for development tools is not what it once was, but I think you've chosen a wise licensing strategy. I doubt I'd know about MySql and Qt if they weren't dual-licensed GPL products. Use the GPL side of things to build product awareness and get contributions, and use the proprietary licensing side to fund your company.
I think you should take a dual approach to marketing, too. Market it as a GPLed open source project: use the internet as a medium to to convice people that your tool is worth their time to investigate and use. Spread the word over the normal channels (mailing lists, newsgroups, blogs, forums, etc). If your tool attracts enough users, you'll get your own community going. Be sure to encourage that--having actual users will spread awareness of your tool and will help you tune it into an even better product.
Since this is also a commercial product, you'll probably need to work the more conventional marketing channels. I don't know what the best way to do that is. Paul Graham, founder of a successful internet startup, speaks highly of PR firms. That might worth looking in to when you reach that point.
Huh? The LGPL allows anyone to build a work on top of (linking to) a library without "giving anything back." It's a weak license that only covers the core library, which is why the FSF recommends against its use. (Weak protection is probably the reason that the LGPL & BSD-style license are massively less popular than the GPLv2.)
I don't see why you have a presumption that Apple has a moral right to use Linux-NTFS's code. The developers of any library--Free or proprietary--have the right (under copyright law) to set the terms of its distribution and use. Usually the developers ask for some form of compensation; developers of proprietary libraries ask for licensing fees and place restrictions on its use (EULAs). Developers of GPLv2 licensed libraries only require that, if their work or a derivative of their work is redistributed (with or without a fee; the GPL allows charging as much as you want!) that it be without additional copyright restrictions. Why do you find that so onerous?
Regarding: "I suspect they just hate companies or people programming for a living", I can't speak for Linux-NTFS's developers. But as a general statement about developers of GPL-licensed programs or libraries, your statement erroneous. The very fact that there are GPLv2 libraries that are sold commercially (MySQL and QT come to mind) is a strong counterexample.
Why brings up an interesting thought: why doesn't Apple offer to pay for a *proprietary license* to use the source code? If they were acquiring any other library, that's what they'd have to do. (It'll probably cost a pretty penny, though, and some developers might not be interested. Once again, their right.)
Why should I share my code with you if you're not going to share* your modifications with me? I'll take tit-for-tat over unconditional cooperation any day! (see Altruism)
* Share in this case is defined loosely: you are allowed (under the GPL) to charge any amount for your changes, but you can't add any extra licensing restrictions that would forbid me from doing the same things I let you do.
Software tends to be winner-take-all: whoever has the most market share ultimately wins. That's why people care so much about these statistics.
For proprietary software, this tends to be because whoever has the most users has the most profit, since development costs are fixed (economists call this "sunk costs"). Therefore, the market share leader can invest in more marketing and product development, getting more users (virtuous circle) and eventually edge out the competition, winning the market.
Sometimes network effects play a role, too: it makes sense to use what everyone else is using, because then your software will be compatible with theirs. The more people that use it, the more value it has to you--which, incidently, is why people often advocate the software that they use. Advocating your favorite piece of software may be a completely rational thing to do!
I'm not entirely sure how this works for Free software that is distributed gratis, like Firefox. But I can guess. Assume some percentage of the total number of users will be contributers to the project: bug writers, documentation contributers, software developers, artists, philanthropists, corportate sponsors, etc. Then, it follows that having more users will lead to more contributors, and ultimately a higher quality product. Thus, Free software is also winner-take-all.
Someone, please, stop the EFF before it's too late. I know they might think of these things as a "why not, let's give it a shot and see what happens" deal, but these trials and the EFF's continued losses are going to be a serious impact on ALL of our futures. I know, I get a chuckle too after seeing the latest story about how they've been laughed out of court, again, and see how riled up people get over it, but this needs to stop now. Our rights, and our (US citizens) futures may depend on it.
I think you should review the Electronic Frontier Foundation's history of accomplishments before making such an over-generalized (and incorrect) statement. They're trying the herculean task of protecting OUR civil liberties at THEIR expense; I think they deserve better than baseless criticism.
I read the Register article where this meme ("EFF is hurting our civil liberties by losing cases") started, and it needs to die. Frankly, I think the lawyers at EFF know a hell of a lot more about winning cases than some hack from The Register, and there's plenty of evidence to prove it.
In any case, if really have some brilliant and constructive idea about how the EFF could win more cases, I'm sure they'd love to hear about it. They have contact information on their website. Knock yourself out.
(Side note: it's amazing how much a reputation can be tarnished by one sensationalized "article".)
I'm pretty sure a more accurate expansion of WINE is: Wine Is Not a (CPU) Emulator. See the Wine FAQ. As you correctly point out, Wine emulates (implements?) the Windows API, using the native CPU to execute code.
But when Qt is using GPL, suddenly the GNU zealots turn around and say, hey that's bad, you can't write proprietary software with it!
I don't think "GNU zealots" would say that. As you correctly point out, Free Software advocates prefer the GPL to LGPL in almost all cases (this link has more information). Now, years ago the Free Software Foundation recommended against use of QT, because back then it was only available under a non-free license. Now that QT is 100% free software (and even better, under the GPL) there's no reason to avoid it.
Personally, I think QT, MySQL, BerkeleyDB and others are setting a good example. To a Free software developer, they're just another GPL-compatible software library ready for reuse. To a proprietary software developer, they're just another piece of software that has to be licensed commercially. From QT's perspective, they get testing/improvements/fixes/more free software from Free software developers, and licensing fees from proprietary software developers. Everyone wins.
you are going to completely get moded down here. Not because you may not be right, but because Linus is worshiped here like a god. Many people here follow him like sheep.
I think you've underestimated strong antiauthoritarian attitudes on Slashdot.
Hang on, you're saying you believe that you would trust a FSF or OSDL-funded study to be impartial? You're saying that if the FSF funded a study comparing GNU to Windows, and the study came back saying "Windows saves you money in the long term, and Microsoft's Shared Source is as good as Free Software for 99% of users", that the FSF would then be happy to publish that study?
The FSF would never commision such a study. Their position is simply that users of software should have certain rights, not that certain licensing models "save you money in the long term." The study you mention would be more likely to come from the OSI.
I was very excited when I first discovered Planeshift, and seriously considering contribution to the project, until I learned of their restrictive (and contradictory!) license terms. To me, Planeshift's schizophrenic licensing policy suggests an ulterior motive.
Contrast to the genuinely Open Source game, The Battle for Wesnoth (http://wesnoth.org/, a turn based strategy game), which hasn't had problems getting fine art content, or with "forking". I suspect one could find other similar examples.
Slashdot Mirror
The password is only available to someone with local access to the system. If your system only has one account (like mine), someone would only be able to read the password if they knew it already.
This vulnerability is serious for computer lab setups, but it's irrelevant for home users that aren't running any remotely accessibly services.
And that, right there, is the crux of the issue: Ubuntu, Fedora Core, Mandriva, SuSE, Gentoo, Debian, Slackware, ... (and hundreds more at distrowatch.com) are all seperate operating systems. I'm well aware that that is the state of things now. What I'm trying to say is, it doesn't have to be that way.
Statically linking (or the equivalent: packaging your own dynamically linked libraries and using those) is an acceptable solution, provided it's used on programs without too many dependencies, and only used on a small scale. Otherwise, the system's memory usage will increase dramatically and performance will go down. The downloadable Linux versions of Firefox and OpenOffice.org take this approach. It works for them because they reimplement almost everything (including their UIs) as internal libraries. They're both genetically related to formerly proprietary codebases, and therefore they don't represent typical Linux programs.
I've been following Autopackage for a long time. It's got a lot of potential. I hope they can work out the kinks, and get a larger body of software packaged, so I can get new software releases without worring about someone packaging it for my distribution. Another interesting project along similar lines is Klik.
Incidently, the Autopackage developers have a page that explains the problems with Linux application portability much better than I did. They also talk about why massive distro-specific package repositories aren't a good idea, in the same FAQ.
That's a ridiculous solution. Why should every distribution be responsible for building a binary package for every Free Software program that's out there, and updating them every release? Sounds like a huge scalability problem to me.
:)
This is *not* a hypothetical problem. One project I follow is Battle for Wesnoth, a cool GPL-ed turn based strategy game. They release new versions, in source tarball form, quite frequenty. Typically, the Windows and MacOS X binaries come out within a day or two of release. And the GNU/Linux binaries? The most recent user submitted version might be several versions out of date. The distribution packaged versions are even more out of date that the user submitted ones. For a fast paced project like Wesnoth, being out of date is bad. (I resort to building from source, because I know exactly which libraries I need, but some distros don't package libSDL-dev, ugh)
Also, I'm not holding FOSS to a "higher" standard. Every other operating system out there besides GNU/Linux *has* a definative baseline you can build applications against, without requiring every application to be integrated into the OS. GNU/Linux is unique in that it has multiple incompatible baselines. If I wanted to release a cool new GPLed application right now I'd have no way of releasing a common binary package that would work for all of my users. There are too many incompatible build environments.
By the way, my previous post wasn't meant as a criticism of FOSS. As a GNU/Linux user, I really want to see this problem solved
Lets take an open source program, which we'll call program X. Program X's developers happily continue adding cool new features and releasing out new versions. The problem is, the only way for GNU/Linux users to get program X is 1) build it from source, or 2) hope someone has built a binary for their distribution. Option #1 is time consuming, and tracking down build dependencies is difficult and error prone. Which leaves us with option #2, the current state of GNU/Linux distributions.
/lib library naming scheme is for). But most distributions have package managers that enforce only one version per libary. Example: KDE in Debian testing/unstable breaks horribly when a new version of kdelibs comes out. Typically, half of the kde packages depend on the old version (because they haven't propegated to unstable yet or were kicked out of testing), so "apt-get update" will happily uninstall half of KDE! The package manager is enforcing an unnecessary constraint. Why can't I have multiple versions of a shared library package installed?
Binary compatibility, or lack thereof, is why the current fragmentation of desktop Linux distributions is so irritating. My #1 criteria for using a distribution is that it has best selection of software. Currently, I'm using Ubuntu because it's Debian with a commitment to a 6-month release cycle.
I've thought a lot about the distribution incompatiblity problem, because it really hurts my desktop GNU/Linux experience. It's not the Linux kernel, which has excellent binary compatibility with userspace. It all boils down to poor package and version management, especially with respect to shared libraries.
The first problem: there's no technical reason why you can't have multiple versions of the same shared library (in fact, that's what the
The other reason for distibution incompatibility is the packages themselves. There are a few different (incompatible) package formats and much worse, each distribution uses its own (incompatible) package naming scheme. Thus, I might have a package build for Fedora Core that depends on libsdl-ttf (Simple DirectMedia Layer True Type Font library), but who knows how it will be packaged or what it will be named in any given distribution?
So, it's the damned package format, package naming, and dumb handing of shared libraries that's to blame. What's the solution? Well, I think the answer is technically simple, but complex to implement. 1) package managers that are smarter about shared libraries, 2) standard package naming scheme, and 3) someone, either library developers or a standards body, needs to build "official" versions of each libary release. This would give GNU/Linux application developers a common "SDK" so they can build their application independently of their distribution.
The market for development tools is not what it once was, but I think you've chosen a wise licensing strategy. I doubt I'd know about MySql and Qt if they weren't dual-licensed GPL products. Use the GPL side of things to build product awareness and get contributions, and use the proprietary licensing side to fund your company.
I think you should take a dual approach to marketing, too. Market it as a GPLed open source project: use the internet as a medium to to convice people that your tool is worth their time to investigate and use. Spread the word over the normal channels (mailing lists, newsgroups, blogs, forums, etc). If your tool attracts enough users, you'll get your own community going. Be sure to encourage that--having actual users will spread awareness of your tool and will help you tune it into an even better product.
Since this is also a commercial product, you'll probably need to work the more conventional marketing channels. I don't know what the best way to do that is. Paul Graham, founder of a successful internet startup, speaks highly of PR firms. That might worth looking in to when you reach that point.
Good luck!
Huh? The LGPL allows anyone to build a work on top of (linking to) a library without "giving anything back." It's a weak license that only covers the core library, which is why the FSF recommends against its use. (Weak protection is probably the reason that the LGPL & BSD-style license are massively less popular than the GPLv2.)
I don't see why you have a presumption that Apple has a moral right to use Linux-NTFS's code. The developers of any library--Free or proprietary--have the right (under copyright law) to set the terms of its distribution and use. Usually the developers ask for some form of compensation; developers of proprietary libraries ask for licensing fees and place restrictions on its use (EULAs). Developers of GPLv2 licensed libraries only require that, if their work or a derivative of their work is redistributed (with or without a fee; the GPL allows charging as much as you want!) that it be without additional copyright restrictions. Why do you find that so onerous?
Regarding: "I suspect they just hate companies or people programming for a living", I can't speak for Linux-NTFS's developers. But as a general statement about developers of GPL-licensed programs or libraries, your statement erroneous. The very fact that there are GPLv2 libraries that are sold commercially (MySQL and QT come to mind) is a strong counterexample.
Why brings up an interesting thought: why doesn't Apple offer to pay for a *proprietary license* to use the source code? If they were acquiring any other library, that's what they'd have to do. (It'll probably cost a pretty penny, though, and some developers might not be interested. Once again, their right.)
Why should I share my code with you if you're not going to share* your modifications with me? I'll take tit-for-tat over unconditional cooperation any day! (see Altruism)
* Share in this case is defined loosely: you are allowed (under the GPL) to charge any amount for your changes, but you can't add any extra licensing restrictions that would forbid me from doing the same things I let you do.
Software tends to be winner-take-all: whoever has the most market share ultimately wins. That's why people care so much about these statistics.
For proprietary software, this tends to be because whoever has the most users has the most profit, since development costs are fixed (economists call this "sunk costs"). Therefore, the market share leader can invest in more marketing and product development, getting more users (virtuous circle) and eventually edge out the competition, winning the market.
Sometimes network effects play a role, too: it makes sense to use what everyone else is using, because then your software will be compatible with theirs. The more people that use it, the more value it has to you--which, incidently, is why people often advocate the software that they use. Advocating your favorite piece of software may be a completely rational thing to do!
I'm not entirely sure how this works for Free software that is distributed gratis, like Firefox. But I can guess. Assume some percentage of the total number of users will be contributers to the project: bug writers, documentation contributers, software developers, artists, philanthropists, corportate sponsors, etc. Then, it follows that having more users will lead to more contributors, and ultimately a higher quality product. Thus, Free software is also winner-take-all.
Someone, please, stop the EFF before it's too late. I know they might think of these things as a "why not, let's give it a shot and see what happens" deal, but these trials and the EFF's continued losses are going to be a serious impact on ALL of our futures. I know, I get a chuckle too after seeing the latest story about how they've been laughed out of court, again, and see how riled up people get over it, but this needs to stop now. Our rights, and our (US citizens) futures may depend on it.
I think you should review the Electronic Frontier Foundation's history of accomplishments before making such an over-generalized (and incorrect) statement. They're trying the herculean task of protecting OUR civil liberties at THEIR expense; I think they deserve better than baseless criticism.
I read the Register article where this meme ("EFF is hurting our civil liberties by losing cases") started, and it needs to die. Frankly, I think the lawyers at EFF know a hell of a lot more about winning cases than some hack from The Register, and there's plenty of evidence to prove it.
In any case, if really have some brilliant and constructive idea about how the EFF could win more cases, I'm sure they'd love to hear about it. They have contact information on their website. Knock yourself out.
(Side note: it's amazing how much a reputation can be tarnished by one sensationalized "article".)
I'm pretty sure a more accurate expansion of WINE is: Wine Is Not a (CPU) Emulator. See the Wine FAQ. As you correctly point out, Wine emulates (implements?) the Windows API, using the native CPU to execute code.
But when Qt is using GPL, suddenly the GNU zealots turn around and say, hey that's bad, you can't write proprietary software with it!
I don't think "GNU zealots" would say that. As you correctly point out, Free Software advocates prefer the GPL to LGPL in almost all cases (this link has more information). Now, years ago the Free Software Foundation recommended against use of QT, because back then it was only available under a non-free license. Now that QT is 100% free software (and even better, under the GPL) there's no reason to avoid it.
Personally, I think QT, MySQL, BerkeleyDB and others are setting a good example. To a Free software developer, they're just another GPL-compatible software library ready for reuse. To a proprietary software developer, they're just another piece of software that has to be licensed commercially. From QT's perspective, they get testing/improvements/fixes/more free software from Free software developers, and licensing fees from proprietary software developers. Everyone wins.
you are going to completely get moded down here. Not because you may not be right, but because Linus is worshiped here like a god. Many people here follow him like sheep.
I think you've underestimated strong antiauthoritarian attitudes on Slashdot.
Hang on, you're saying you believe that you would trust a FSF or OSDL-funded study to be impartial? You're saying that if the FSF funded a study comparing GNU to Windows, and the study came back saying "Windows saves you money in the long term, and Microsoft's Shared Source is as good as Free Software for 99% of users", that the FSF would then be happy to publish that study?
The FSF would never commision such a study. Their position is simply that users of software should have certain rights, not that certain licensing models "save you money in the long term." The study you mention would be more likely to come from the OSI.
Is your Windows XP on a secondary drive? If so, you may need to add these two lines to your Windows XP entry in your menu.lst/grub.conf file:
map (hd0) (hd1)
map (hd1) (hd0)
With those lines added, your Windows entry will look something like this:
title Windows XP
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd1,0)
makeactive
chainloader +1
Those two lines do some magic that makes Windows think it's on the primary drive, allowing it to boot up.
I was very excited when I first discovered Planeshift, and seriously considering contribution to the project, until I learned of their restrictive (and contradictory!) license terms. To me, Planeshift's schizophrenic licensing policy suggests an ulterior motive. Contrast to the genuinely Open Source game, The Battle for Wesnoth (http://wesnoth.org/, a turn based strategy game), which hasn't had problems getting fine art content, or with "forking". I suspect one could find other similar examples.
...being FEMALE!
Or at least, that seems to be the gist of Jeff Minter's anti-piracy argument.
I couldn't even finish reading his article.