Proprietary Software is (so far) a closed road to nowhere by Bero, Red Hat
Richard M. Stallman, the closest thing GNU has to a cult hero, calls Microsoft Windows a disruptive technology.
Microsoft Windows is not a disruptive technology. It's a wannabe operating system, and OSes aren't a thread to anyone - and if they were, it surely wouldn't be a good thing. Richard apparently is referring to the proprietary software movement and the sea change behind Microsoft products that has made them unsettling to more than one or two OS vendors.
What amazes me most is that proprietary software has gained so much momentum without showing any goods. It's a dot-com--all-hype and speculation and no fundamentals. It's like an onion in a bushel of apples. Someone might notice that it looks and tastes different, but peel away its layers, and there's nothing there.
In several years, one of the more high-profile proprietary software projects at its time - Microsoft Bob - has released exactly zero used copies of its interface. It won't be until Microsoft throws a copy into open source that anything usable will be released. And the result is a product that might have some good but not earth-shattering.
In fact, the best parts of Microsoft Bob have nothing to do with proprietaryness. The most important part of Microsoft Bob is that it runs on Windows - it's Microsoft's obvious attempt to tie in the product to a bunch of for-profit wannabe OS products.
Although Microsoft has had incredible stock market valuations at one time, it's very much down to earth right now. This means that they'll quickly have to expand beyond valuations centered on Windows.
Microsoft took the bait, creating MSN, an online service that, while fairly bad, had not much to do with Windows. Perhaps Microsoft needed to add another color to its spectrum. Maybe it will next buy AT&T to flesh out its all-American offerings.
It's clear that Windows has a future and that it's still attracting dumb people. Proprietary Software, on the other hand, appears to be struggling.
The reason is simple: People gravitate toward products, and proprietary software is not geared to create but to make money at the cost of freedom, stability and usability. It's best at tearing apart the establishment because it locks out valuable programmers who might want to improve the products.
But proprietary software advocates should face the facts: Put up some goods or your establishment will be ripped apart, too.
Are you a proprietary software advocate, or do you just not care? Let me know with the "Reply" button below.
I'm not planning to start a new license flamewar here (any open source license is ok with me), but there are a couple of reasons to prefer GPL over BSD, depending on what you want to do. The danger of the BSD license is that anyone can "steal" the code, modify it or not, and make lots of money selling a binary-only version, without giving anything back to the people who originally wrote the code. This has happened before ("Microsoft's" command line ftp client is actually a SuckOS port of the BSD ftp client). If a piece of software is GPL or LGPL, they'd have to give back their extensions/ports/fixes/whatever, so the community (and at least as important, the original programmer) would benefit from it.
Doesn't install on systems that have KDE 2.0, because it wants to execute a konsole with -title (invalid option), so you have to make it start something else.
Workaround #2: Remove the -title stuff or change the order in which terms are searched. If you do this, you also have to remove the checksum code, because you just changed the code. To do that, comment out lines 116 to 121.
:) I must admit I can't imagine what their code looks like - I've never worked in a closed-source environment or any other environment motivated only by salaries. However, this particular thing should be VERY easy to track down even in totally messed up code. We all know the password is stored backwards in the binary, so it all comes down to searching for the string "!seineew era sreenigne epacsteN" in the code, then looking where it's accessed and removing that code.
Anyone @microsoft.com: Here's an offer. Give me the source code (to all of Windoze and this dll) and I'll fix this backdoor in less than 5 minutes. Only condition: I want to be able and allowed to submit the code to wine for whatever use they see fit.;)
It would seem far more useful to me if source was "open" in the sense that you could get a copy of the code on production of a reasonable description of what you planned to do with it, what improvement you wanted to make, plus at least two references from people who were prepared to establish your bona fides. Kind of like the criteria for getting a reader's ticket to a law library.
For what purpose? I think you're misunderstanding the concept of open source. It's not that everybody can just put in changes that will affect anyone but himself. No maintainer would permit a patch introducing a backdoor into the base release. Even if a maintainer did it, someone else would notice, bugtraq, slashdot and others would inform the public, and that maintainer wouldn't keep the package for long (open source licenses generally permit forks), and a fixed version would be made available immediately.
Requiring to describe what you want to do is an unnecessary problem for people who just want to read the code for learning, or to see whether or not something can be optimized. Not every contributor will (or can/should) become a major contributor. Requiring references is even worse - how would anyone get started? If open source required references, I'd probably be cleaning toilets or selling shoes instead of working for Red Hat - when I got started, I didn't know anyone else doing open source stuff, so by your terms, I wouldn't have seen a single line of code, much less started extending and fixing things...
With the same day's workaround being "delete the file and the functionality it comes with". That would be much like "yes, we're aware of the latest sendmail root-shell exploit. The fix is to rpm -e sendmail and lose your mail". Fixing a security leak caused by bugs can take a while (needs to be tracked down etc.) - fixing an INTENTIONAL BACKDOOR, especially if you know what to look for (such as the weenies string) is a matter of a few minutes, and I don't see why they didn't release a fixed dll.
Actually the example you've cited shows that you SHOULD be using Linux (or *BSD or whatever). You won't find any "Microsoft engineers are weenies!" backdoors in open source code, at least not a couple of days after it has been released. At Red Hat (the same is probably true of most other distributors), we do check source for backdoors before putting it in the distribution. (Of course we can't guarantee we find all bugs that can lead to security problems though). Also, experience shows open-source is usually FASTER at providing fixes, and you have the advantage of "if your distributor doesn't provide a fix, just get it from another".
The C compiler backdoor mentioned affected only people who installed the binary, instead of recompiling the compiler themselves - binaries that have been tampered with can exist both in open source and closed source software. With open source, however, you can make sure you're actually using what the source generates. If, for example, you're using Red Hat Linux and you don't trust us for whatever reason, all it takes is "rpm --rebuild/mnt/cdrom/SRPMS/* ; rpm -U --force/usr/src/redhat/RPMS/yourarch/*/usr/src/redhat/RPMS/noarch/*". You can't do something like this with closed-source software, so this is actually another argument for open source.
While it is right that a lot of people just use open source applications than actually reading the code, the fact that everyone can read it is still a big advantage - if someone breaks into my system, at least I can immediately figure out how and FIX IT instead of waiting for Microsoft or whoever to issue an updated binary. Alternatively, if I don't have the knowledge to fix it, I can just hire someone to do it (probably cheaper than taking the server offline until Microsoft releases a fix).
Also, many people working on the same source has the definite advantage that everyone can use other people's fixes - if someone finds a bug in, say, sendmail, and a Linux person finds a quick fix, chances are BSD users can just use the same fix immediately (and vice versa). (Try applying an OS/2 fixpack to Windows NT as a counter-example in the proprietary world;) ).
The article states Windows 2000 is not affected, so here's the only reason why anyone should update to Windows 2000 and pay yet another $1,000,000,000 to M$ and its hardware partners...
If this turns out NOT to be YAAFJ(tm) (Yet Another April Fools Joke), feel free to drop a note to UFO - I'm quite sure we can find someone to continue the work.
Actually it doesn't tell anything about the quality of open source projects, or even about the UFO project itself.
What did you expect? Every project has to start somewhere, and (of course) I didn't send a piece of SPAM mail around the world asking people to drop their packages off. In fact, slashdot was the initial announcement of the project. We're at 7 packages now, I'm expecting to see more when we actually start doing something about the packages in addition to providing a "trading place".
Starting an open source project is very possible without an existing code base; most of the bigger projects started from scratch.
Despite the fact that the project started out at Red Hat, is run by a Red Hat developer and has several other Red Hat people backing it, this is not officially a Red Hat project, so (for now) the question is not "how much time and effort will Red Hat put into it", but "how much time and effort will YOU put into it" - it's a project that needs participants. We need people to help maintaining packages, both true maintainers and interim maintainers.
There's no guarantee that a project started out being dumped while in the main() { } phase will get anywhere. There's no guarantee of the opposite either.
As for cooperating with other parties, the answer is "ideally yes" - but of course we can't force anyone to help us out.
But knowing the nature of open source, my guess is that at least most of the time, this type of cooperation will work.
Good idea... I'll add that in the next version. (As you can probably tell from the looks of the web page, the whole project was hacked up in about 2 days. This includes writing the CGI library we're using.)
The purpose of the project is to keep projects alive with the approval of the previous maintainer(s). Unless someone can't be contacted (or ignores all queries), we don't intend to create forks on our own (at least not at this time; as you can probably guess if you've had a look at our web pages, we're just starting...)
I'd agree that #3 is the most important one... Also you forgot #4: The program does everything its author needed it to do, so there's no reason for him to make any more changes.
#4 is quite common, as well. (Why add a simple user interface if find . -name "*.c" |xargs perl -pi -e "s,mayn,main,g" works for me?;) )
If I had infinite amounts of money, I'd probably help with the project you suggested, but I'm a programmer, not a millionaire, so I have to try solving things in ways I actually CAN.
Utopia for me would be if I could work on various OSS projects like GIMP, GNOME, sawmill, VIM and my own projects, and make a decent salary
Much what I'm doing...;) If you're good, send your resume to Red Hat. If you aren't, try one of the other distributors...;))
We noticed something like the project was needed when I noticed just how many packages from Red Hat Linux 6.0 are still the same base version in 6.2... The priority was getting up something that works, not picking the ideal name. I'll admit I'm not very creative about names any day (check the scripts from the Free Film Project for another fine example of me not being able to pick names;) ) - but improvement is what open source is all about: If you have a better name, let us know. I'd rather have a project without a fancy name up and running than just delaying it forever.
Some projects get abandoned for good reasons aside from lack of time. Those aren't the ones we're interested in. Check the FAQ - basically any *still interesting* package qualifies. If a maintainer drops a package for a good reason, he won't drop it off at UFO, and we don't "steal" packages without the maintainer's consent, unless there's no way to contact the maintainer.
For interim maintainers, I'm planning to use a very simple algorithm - if you've already had a look at the "join" and "add" pages, you'll see we're asking a number of questions - they'll be used to check who can take care of a particular program.
For the future maintainers, see the FAQ.
If someone notices later that he doesn't want to take the package after all, he can just drop it back to UFO - we'll always have some people to look after them.
Since I created the project, I guess it's up to me to answer this...
This one is more or less answered in the FAQ. Temporary maintainers will just have to work together. Real maintainers are supposed to tell the temporary maintainers where they want to take the package, and show at least a patch to show they can do something.
Aside from that, first come first serve - once a package has found a new maintainer, it'll be removed from UFO (we can continue hosting it though).
I haven't really thought about this, but I'd think someone who has maintained a program before will always have something to offer (experience, for instance). I guess it'll be a bit dependent on the particular package.
This depends pretty much on the license - unless it's not open source, we don't intend to change licensing.
The BSD license in general permits closed-source forks, the GPL doesn't (and licenses can't be changed without the consent of all contributors)
I'd welcome feedback on these and other issues very much - if you have any thoughts on this, let me know (either here or at bero@redhat.com)
The above note is definitely a fake. I actually worked for Mandrake until some time last summer. There have been a couple of problems, but no plans whatsoever to go proprietary back then, and I'm absolutely certain this did not change (I may work for the competition now, but I still know the people around at Mandrake).
Anonymous coward: Do you work for Microsoft, by any chance?
Binary compatibility. Stuff compiled on 6.2 is supposed to run on prior 6.x releases, which is not the case if we had updated gcc (c++ changes). gcc 2.95.3 (or whatever is current by then, maybe 2.96, maybe 3.0) will be in 7.0.
Slashdot Mirror
by Bero, Red Hat
Richard M. Stallman, the closest thing GNU has to a cult hero, calls Microsoft Windows a disruptive technology.
Microsoft Windows is not a disruptive technology. It's a wannabe operating system, and OSes aren't a thread to anyone - and if they were, it surely wouldn't be a good thing. Richard apparently is referring to the proprietary software movement and the sea change behind Microsoft products that has made them unsettling to more than one or two OS vendors.
What amazes me most is that proprietary software has gained so much momentum without showing any goods. It's a dot-com--all-hype and speculation and no fundamentals. It's like an onion in a bushel of apples. Someone might notice that it looks and tastes different, but peel away its layers, and there's nothing there.
In several years, one of the more high-profile proprietary software projects at its time - Microsoft Bob - has released exactly zero used copies of its interface. It won't be until Microsoft throws a copy into open source that anything usable will be released. And the result is a product that might have some good but not earth-shattering.
In fact, the best parts of Microsoft Bob have nothing to do with proprietaryness. The most important part of Microsoft Bob is that it runs on Windows - it's Microsoft's obvious attempt to tie in the product to a bunch of for-profit wannabe OS products.
Although Microsoft has had incredible stock market valuations at one time, it's very much down to earth right now. This means that they'll quickly have to expand beyond valuations centered on Windows.
Microsoft took the bait, creating MSN, an online service that, while fairly bad, had not much to do with Windows. Perhaps Microsoft needed to add another color to its spectrum. Maybe it will next buy AT&T to flesh out its all-American offerings.
It's clear that Windows has a future and that it's still attracting dumb people. Proprietary Software, on the other hand, appears to be struggling.
The reason is simple: People gravitate toward products, and proprietary software is not geared to create but to make money at the cost of freedom, stability and usability. It's best at tearing apart the establishment because it locks out valuable programmers who might want to improve the products.
But proprietary software advocates should face the facts: Put up some goods or your establishment will be ripped apart, too.
Are you a proprietary software advocate, or do you just not care? Let me know with the "Reply" button below.
I'm not planning to start a new license flamewar here (any open source license is ok with me), but there are
a couple of reasons to prefer GPL over BSD, depending on what you want to do.
The danger of the BSD license is that anyone can "steal" the code, modify it or not, and make lots of money selling a binary-only version, without giving anything back to the people who originally wrote the code.
This has happened before ("Microsoft's" command line ftp client is actually a SuckOS port of the BSD ftp client).
If a piece of software is GPL or LGPL, they'd have to give back their extensions/ports/fixes/whatever, so the community (and at least as important, the original programmer) would benefit from it.
Doesn't install on systems that have KDE 2.0, because it wants to execute a konsole with -title (invalid option), so you have to make it start something else.
/usr/bin/konsole /usr/bin/konsole.DONTUSE ./PhotogenicsB86.sh /usr/bin/konsole.DONTUSE /usr/bin/konsole
Workaround #1:
# mv
#
# mv
Workaround #2:
Remove the -title stuff or change the order in which terms are searched.
If you do this, you also have to remove the
checksum code, because you just changed the code.
To do that, comment out lines 116 to 121.
:) I must admit I can't imagine what their code looks like - I've never worked in a closed-source environment or any other environment motivated only by salaries.
;)
However, this particular thing should be VERY easy to track down even in totally messed up code.
We all know the password is stored backwards in the binary, so it all comes down to searching for the string
"!seineew era sreenigne epacsteN" in the code, then looking where it's accessed and
removing that code.
Anyone @microsoft.com: Here's an offer. Give me the source code (to all of Windoze and this dll) and I'll fix this backdoor in less than 5 minutes. Only condition: I want to be able and allowed to
submit the code to wine for whatever use they see fit.
It would seem far more useful to me if source was "open" in the sense
that you could get a copy of the code on production of a reasonable
description of what you planned to do with it, what improvement you
wanted to make, plus at least two references from people who were
prepared to establish your bona fides. Kind of like the criteria for
getting a reader's ticket to a law library.
For what purpose? I think you're misunderstanding the concept of open source.
It's not that everybody can just put in changes that will affect anyone but himself. No maintainer would permit a patch introducing a backdoor into the base release.
Even if a maintainer did it, someone else would notice, bugtraq, slashdot and others would inform the public, and that maintainer wouldn't keep the package for long (open source licenses generally permit forks), and a fixed version would be made available immediately.
Requiring to describe what you want to do is an unnecessary problem for people who just want to read the code for learning, or to see whether or not something can be optimized. Not every contributor will (or can/should) become a major contributor.
Requiring references is even worse - how would anyone get started?
If open source required references, I'd probably be cleaning toilets or selling shoes instead of working for Red Hat - when I got started, I didn't know anyone else doing open source stuff, so by your terms, I wouldn't have seen a single line of code, much less started extending and fixing things...
With the same day's workaround being "delete the file and the functionality it comes with".
That would be much like "yes, we're aware of the latest sendmail root-shell exploit. The fix is to rpm -e sendmail and lose your mail".
Fixing a security leak caused by bugs can take a while (needs to be tracked down etc.) - fixing an INTENTIONAL BACKDOOR, especially if you know what to look for (such as the weenies string) is a matter of a few minutes, and I don't see why they didn't release a fixed dll.
Actually the example you've cited shows that you SHOULD be using Linux (or *BSD or whatever).
You won't find any "Microsoft engineers are weenies!" backdoors in open source code, at least not a couple of days
after it has been released.
At Red Hat (the same is probably true of most other distributors), we do check
source for backdoors before putting it in the distribution. (Of course we can't guarantee we find all bugs that can lead to security problems though).
Also, experience shows open-source is usually FASTER at providing fixes, and you have the advantage of
"if your distributor doesn't provide a fix, just get it from another".
The C compiler backdoor mentioned affected only people who installed the binary, /mnt/cdrom/SRPMS/* ; rpm -U --force /usr/src/redhat/RPMS/yourarch/* /usr/src/redhat/RPMS/noarch/*". You can't do something like this with closed-source software, so this is actually another argument for open source.
;) ).
instead of recompiling the compiler themselves - binaries that have been tampered with
can exist both in open source and closed source software. With open source, however, you can make sure you're actually using what the source generates.
If, for example, you're using Red Hat Linux and you don't trust us for whatever reason, all it takes is
"rpm --rebuild
While it is right that a lot of people just use open source applications than actually reading the code, the fact
that everyone can read it is still a big advantage - if someone breaks into my system, at least I can immediately figure out how and FIX IT instead of waiting for Microsoft or whoever to issue an updated binary.
Alternatively, if I don't have the knowledge to fix it, I can just hire someone to do it (probably cheaper than taking the server offline until Microsoft releases a fix).
Also, many people working on the same source has the definite
advantage that everyone can use other people's fixes - if someone finds a bug in, say, sendmail, and a Linux person finds a quick fix, chances are BSD users can just use the same fix immediately (and vice versa).
(Try applying an OS/2 fixpack to Windows NT as a counter-example in the proprietary world
The article states Windows 2000 is not affected,
so here's the only reason why anyone should update to Windows 2000 and pay yet another $1,000,000,000 to M$ and its hardware partners...
If this turns out NOT to be YAAFJ(tm) (Yet Another
April Fools Joke), feel free to drop a note to
UFO -
I'm quite sure we can find someone to continue
the work.
Actually it doesn't tell anything about the quality of open source projects, or even about the UFO project itself.
What did you expect? Every project has to start somewhere, and (of course) I didn't send a piece of SPAM mail around the world asking people to drop their packages off.
In fact, slashdot was the initial announcement of the project.
We're at 7 packages now, I'm expecting to see more when we actually start doing something about the packages in addition to providing a "trading place".
Starting an open source project is very possible without an existing code base; most of the bigger projects started from scratch.
Despite the fact that the project started out at Red Hat, is run by a Red Hat developer and has several other Red Hat people backing it, this is not officially a Red Hat project, so (for now) the question is not "how much time and effort will Red Hat put into it", but "how much time and effort will YOU put into it" - it's a project that needs participants. We need people to help maintaining packages, both true maintainers and interim maintainers.
There's no guarantee that a project started out being dumped while in the main() { } phase will get anywhere. There's no guarantee of the opposite either.
As for cooperating with other parties, the answer is "ideally yes" - but of course we can't force anyone to help us out.
But knowing the nature of open source, my guess is that at least most of the time, this type of cooperation will work.
Good idea... I'll add that in the next version.
(As you can probably tell from the looks of the web page, the whole project was hacked up in about 2 days. This includes writing the CGI library we're using.)
The purpose of the project is to keep projects alive with the approval of the previous maintainer(s).
Unless someone can't be contacted (or ignores all queries), we don't intend to create forks on our own (at least not at this time; as you can probably guess if you've had a look at our web pages, we're just starting...)
I'd agree that #3 is the most important one...
;) )
;) ;))
Also you forgot
#4: The program does everything its author needed it to do, so there's no reason for him to make any
more changes.
#4 is quite common, as well. (Why add a simple user interface if find . -name "*.c" |xargs perl -pi -e "s,mayn,main,g" works for me?
If I had infinite amounts of money, I'd probably help with the project you suggested, but I'm a programmer, not a millionaire, so I have to try solving things in ways I actually CAN.
Utopia for me would be if I could work on various OSS projects like GIMP, GNOME, sawmill, VIM and my own projects, and make a decent salary
Much what I'm doing...
If you're good, send your resume to Red Hat.
If you aren't, try one of the other distributors...
The interim maintainers that are taking care of the package while there's no official maintainer will make that decision.
We can already do that...
;)
Write a README, and a piece of code saying something along the lines of
int main(int argc, char **argv)
{
}
Then drop it off as unmaintained code.
Chances are I (or another admin) will approve the package if the idea is interesting enough.
We noticed something like the project was needed when I noticed just how many packages from Red Hat Linux 6.0 are still the same base version in 6.2... ;) ) - but improvement is what open source is all about: If you have a better name, let us know.
The priority was getting up something that works, not picking the ideal name. I'll admit I'm not very creative about names any day (check the scripts from the Free Film Project for another fine example of me not being able to pick names
I'd rather have a project without a fancy name up and running than just delaying it forever.
Some projects get abandoned for good reasons aside from lack of time.
Those aren't the ones we're interested in.
Check the FAQ - basically any *still interesting* package qualifies.
If a maintainer drops a package for a good reason, he won't drop it off at UFO, and we don't "steal" packages without the maintainer's consent, unless there's no way to contact the maintainer.
For interim maintainers, I'm planning to use a very simple algorithm - if you've already had a look at the "join" and "add" pages, you'll see we're asking a number of questions - they'll be used to check who can take care of a particular program.
For the future maintainers, see the FAQ.
If someone notices later that he doesn't want to take the package after all, he can just drop it back to UFO - we'll always have some people to look after them.
Aside from that, first come first serve - once a package has found a new maintainer, it'll be removed from UFO (we can continue hosting it though).
The BSD license in general permits closed-source forks, the GPL doesn't (and licenses can't be changed without the consent of all contributors)
I'd welcome feedback on these and other issues very much - if you have any thoughts on this, let me know (either here or at bero@redhat.com)
The above note is definitely a fake.
I actually worked for Mandrake until some time last summer. There have been a couple of problems, but no plans whatsoever to go proprietary back then, and I'm absolutely certain this did not change (I may work for the competition now, but I still know the people around at Mandrake).
Anonymous coward: Do you work for Microsoft, by any chance?
I'm currently running 2.3.99 compiled with gcc 2.95.3, so yes, it works.
Binary compatibility.
Stuff compiled on 6.2 is supposed to run on prior 6.x releases, which is not the case if we had updated gcc (c++ changes).
gcc 2.95.3 (or whatever is current by then, maybe 2.96, maybe 3.0) will be in 7.0.
We're including it in powertools.