Would it help if Red Hat released a very public beta distro prior to the actual distro? Like a "Red Hat 7 Beta" distro?
They probably have a beta posted on their FTP site, but that's not what I'm talking about. I'm suggesting a much more grand release, automatic free CD's sent to customers who have purchased multiple Red Hat products, etc.
That would let these 2000+ bugs be worked on by developers before people start installing the distro on critical systems. From reading comments on RH7 the problem is not really the quantity of bugs (just over 2000 is not many, there were several times that with Windows 2000 when it came out); the problem is that several basic functions were inherently broken/altered - people had problems with *ping* and *gcc*, for crying out loud. These are not frills, they are essential to daily operations on Linux. A beta period would have captured comments from early users and supporters and (a) guided Red Hat in making decisions about what to include, and (b) given the developers time to iron out the most pressing bugs.
Obviously a beta works best with the most number of users, and a lot of people like me enjoy Red Hat but we use it mostly at work where we don't want to introduce potential problems. So you'd want the beta installed on less important systems and home/hobby systems. Perhaps Red Hat could combine this with an incentive program. For example, if you download and install the beta distro, you can run a program to register with redhat.com and your username is credited with $15 off the purchase of the full package when it comes out... or they send you a cool T-shirt or something. Whatever.
Of course "beta" packages are a huge tool of Microsoft, but in their case they use them for marketing purposes, to grab mindshare early on. It would be nice to see a company run a serious beta program with the objective of connecting with customers. This would be another way to differentiate Red Hat from Microsoft.
Just MHO.
Re:A Better Written article on Why X-Windows is Ba
on
X Windows Must Die!
·
· Score: 1
How easy is it for me to handle this using getopt ?
A lot of us out there in corporate environments are using Red Hat. What would you say is the biggest difference between Debian and Red Hat? Also, do you see Debian as a hacker's distro, or is there a push to invite the business community to embrace it (like Red Hat is doing with their distro)?
For the Web developer, the tools to build, test and deploy engaging Web sites are hopelessly inadequate. Many focus more on building attractive rather than useful Web sites.
Hmz, I think its kinda harsh and very arrogant to call tools like Dreamweaver "inadequate".
Actually I don't see any qualification to show that they refer strictly about non-MS tools. Visual InterDev and FrontPage are in the category of web design tools they speak of. Wow! I never thought I'd see Microsoft actually admit that their software is crap. Here it is in black and white.;)
please don't continue this about the.vbs files. The same could easily happen under the UNIX-like systems. I could attach a Perl script and say "Please run this for free money" and the dumb user runs it and the script does what it does. Same thing. There are just more clueless Windows users.
Except, of course, on Unix it would run as your user and thus only be able to write to a handful of files, and certainly not the system binaries. On Windows it could, oh, I don't know... format your hard drive?
The most important thing to do is buy Linux versions of games wherever possible, and ignore the Windows versions. I just set up Red Hat Linux 6.2 Pro on my brand new eMachines eMonster, and to celebrate, I went out to buy Quake II and Quake III for Linux. It's like Carmack said, when you have a choice, always buy the Linux version so the numbers will speak for themselves. It's that simple and that difficult.
If you write an application that depends on a GPLed program, and won't run with a replacement, then it's likely going to infringe. But if you write a program, like a compiler front-end, and it simply has the option to use a GPLed compiler, among others, then it doesn't infringe.
I think it would also be legal if your non-GPL front-end relied on GPL'd code provided that you also happened to be the author (copyright holder, more specifically) of the GPL'd code.
Actually, I'd like some feedback on that, because I plan on doing it soon. I've been wrestling with a decision on a project I want to start at my company - to release it as GPL and participate in the great open source movement, or to release it as shareware/commercial software and actually pay some bills! At the moment, I think I want to create it in parts - a command-line utility that provides all of the core functionality, GPL'd, and then a web-based GUI and some extra utilities to work on the output data as a fee-based add-on. I think this strikes a good balance between serving my fellow hackers who will use the command-line version (and write their own front-ends maybe), and still providing corporations who might use the product with somewhere to send a check, in return for an "official" GUI/enhancement bundle.
Does anyone know of projects that already work like this? I suppose that's similar to what Red Hat does, right?
An answer is to gather together AHEAD OF TIME a group of motivated buyers (for whom the software solves an important problem) who commit to pay for a particular software application/feature/bugfix if someone succeeds in developing it. Upon completion, it can be released as open source and freely copied. The buyers must be types who don't worry about free riders -- their only concern must be that they want this software to exist to solve some problem/need they have.
And, if the price of funding an OSS solution to their problem is less than the fees for custom programming, then it may well be justified for more buyers than you might imagine.
In the long run, OSS projects are inherently cheaper. All you must do is establish a solid, well-written base of code, and release that. Then, bug fixes, patches, enhancements (and effectively the remaining work on the project) will filter in over time as other developers worldwide use your software for their own needs and add to it. Since this work is free and can represent a sizable portion of the project, the total cost of such a project cannot possibly be more expensive than a closed-source version.
The "price" of the cheaper OSS solution is that you cannot prevent your competitors from using your developed software, you cannot sell your software in the traditional way (or at least not as effectively as the public become saavy to OSS), and you might not get an OSS solution as fast as a custom programmed solution (debatable). On the other hand, if a buyer wants the satisfaction of barring competitors from the code, complete intellectual property control, or rapid development, then they are free to pay the premium of closed source. There will always be such buyers.
It's much eaiser to do C-like things in a bug free manner in perl. Add to this that perl is a "scripting" tool, as opposed to a compiler (yes, the language is "compiled," but not in the same sense as with a true compiler) so you don't have (well, mostly don't have) the make complexities; editing code is also building code, so rapid toolmaking is facilitated.
I agree; I have rapidly coded and debugged many great Perl scripts because of its interpreted nature. However, after using Perl for a couple of years now, and finally working on web sites where Perl scripts have to handle complex search queries from thousands of users a day (and having the server come to a crawl because of it) I'm beginning to question whether Perl scripts shouldn't be compiled into executables for production use. In other words, the intepreter/compiler used now is excellent for platform portability and rapid development, but perhaps the Perl code should be made into executable code to make it faster before production deployment. Can this be done? Wouldn't it increase the speed? Why isn't it the normal habit? (Or is it and I just didn't realize?)
I expect you might say, "You're just using the wrong tool... use C instead of Perl", but that just seems like a cop out, because CGI scripting and all the activities of CGIs are so much more elegantly handled by Perl.
Slashdot Mirror
Considering one in ten probably got installed, that's 50 installations. Big whoop.
Compare that to the scale of a Microsoft beta with the huge promotions they run. THAT was my point.
Would it help if Red Hat released a very public beta distro prior to the actual distro? Like a "Red Hat 7 Beta" distro?
They probably have a beta posted on their FTP site, but that's not what I'm talking about. I'm suggesting a much more grand release, automatic free CD's sent to customers who have purchased multiple Red Hat products, etc.
That would let these 2000+ bugs be worked on by developers before people start installing the distro on critical systems. From reading comments on RH7 the problem is not really the quantity of bugs (just over 2000 is not many, there were several times that with Windows 2000 when it came out); the problem is that several basic functions were inherently broken/altered - people had problems with *ping* and *gcc*, for crying out loud. These are not frills, they are essential to daily operations on Linux. A beta period would have captured comments from early users and supporters and (a) guided Red Hat in making decisions about what to include, and (b) given the developers time to iron out the most pressing bugs.
Obviously a beta works best with the most number of users, and a lot of people like me enjoy Red Hat but we use it mostly at work where we don't want to introduce potential problems. So you'd want the beta installed on less important systems and home/hobby systems. Perhaps Red Hat could combine this with an incentive program. For example, if you download and install the beta distro, you can run a program to register with redhat.com and your username is credited with $15 off the purchase of the full package when it comes out... or they send you a cool T-shirt or something. Whatever.
Of course "beta" packages are a huge tool of Microsoft, but in their case they use them for marketing purposes, to grab mindshare early on. It would be nice to see a company run a serious beta program with the objective of connecting with customers. This would be another way to differentiate Red Hat from Microsoft.
Just MHO.
I think:
startproxy -port 12121 -blockads -filter '*.gif *.jpg *.js'
...would do the trick (quotes).
Wouldn't you have to do that anyway to avoid shell globbing?
A lot of us out there in corporate environments are using Red Hat. What would you say is the biggest difference between Debian and Red Hat? Also, do you see Debian as a hacker's distro, or is there a push to invite the business community to embrace it (like Red Hat is doing with their distro)?
Actually I don't see any qualification to show that they refer strictly about non-MS tools. Visual InterDev and FrontPage are in the category of web design tools they speak of. Wow! I never thought I'd see Microsoft actually admit that their software is crap. Here it is in black and white. ;)
Except, of course, on Unix it would run as your user and thus only be able to write to a handful of files, and certainly not the system binaries. On Windows it could, oh, I don't know... format your hard drive?
The most important thing to do is buy Linux versions of games wherever possible, and ignore the Windows versions. I just set up Red Hat Linux 6.2 Pro on my brand new eMachines eMonster, and to celebrate, I went out to buy Quake II and Quake III for Linux. It's like Carmack said, when you have a choice, always buy the Linux version so the numbers will speak for themselves. It's that simple and that difficult.
I think it would also be legal if your non-GPL front-end relied on GPL'd code provided that you also happened to be the author (copyright holder, more specifically) of the GPL'd code.
Actually, I'd like some feedback on that, because I plan on doing it soon. I've been wrestling with a decision on a project I want to start at my company - to release it as GPL and participate in the great open source movement, or to release it as shareware/commercial software and actually pay some bills! At the moment, I think I want to create it in parts - a command-line utility that provides all of the core functionality, GPL'd, and then a web-based GUI and some extra utilities to work on the output data as a fee-based add-on. I think this strikes a good balance between serving my fellow hackers who will use the command-line version (and write their own front-ends maybe), and still providing corporations who might use the product with somewhere to send a check, in return for an "official" GUI/enhancement bundle.
Does anyone know of projects that already work like this? I suppose that's similar to what Red Hat does, right?
And, if the price of funding an OSS solution to their problem is less than the fees for custom programming, then it may well be justified for more buyers than you might imagine.
In the long run, OSS projects are inherently cheaper. All you must do is establish a solid, well-written base of code, and release that. Then, bug fixes, patches, enhancements (and effectively the remaining work on the project) will filter in over time as other developers worldwide use your software for their own needs and add to it. Since this work is free and can represent a sizable portion of the project, the total cost of such a project cannot possibly be more expensive than a closed-source version.
The "price" of the cheaper OSS solution is that you cannot prevent your competitors from using your developed software, you cannot sell your software in the traditional way (or at least not as effectively as the public become saavy to OSS), and you might not get an OSS solution as fast as a custom programmed solution (debatable). On the other hand, if a buyer wants the satisfaction of barring competitors from the code, complete intellectual property control, or rapid development, then they are free to pay the premium of closed source. There will always be such buyers.
I agree; I have rapidly coded and debugged many great Perl scripts because of its interpreted nature. However, after using Perl for a couple of years now, and finally working on web sites where Perl scripts have to handle complex search queries from thousands of users a day (and having the server come to a crawl because of it) I'm beginning to question whether Perl scripts shouldn't be compiled into executables for production use. In other words, the intepreter/compiler used now is excellent for platform portability and rapid development, but perhaps the Perl code should be made into executable code to make it faster before production deployment. Can this be done? Wouldn't it increase the speed? Why isn't it the normal habit? (Or is it and I just didn't realize?)
I expect you might say, "You're just using the wrong tool... use C instead of Perl", but that just seems like a cop out, because CGI scripting and all the activities of CGIs are so much more elegantly handled by Perl.