There's certainly something to be said for that (thus my support for the LSB). Still, it only helps on the binary front. Source packages aren't usually focused on Solaris or BSD any more than they are on Red Hat or SuSE. Such is the price of flexibility. We're not going to see foolproof source installs unless everyone settles on one tightly-controlled *nix. That probably won't be happening in this lifetime.
I install a lot of packages this way on Solaris at work and on Linux at home. When it works it's great, but I find that it's only problem-free about 70% of the time. Quite often I need to update a shared library, hand-edit a Makefile, or tweak a line or two of C code. Not too hard for a sysadmin, but far more complicated than using an InstallShield wizard.
One big problem is that the rapid changes in the various components of the OS aren't coordinated in any real way. There's something to be said for the concept of service pack levels, even if Windows doesn't stick to it. If the underlying components can become a little more predictable (and I'm hoping that the LSB can manage this), then source distributions could be installed through a reliable, friendly interface.
Almost forgot: one other advantage of binaries is that they're a lot quicker to install. Especially on old, slow machines.
I agree that dual boot is a necessity for most people, but it's a lot easier to get a Linux install right if it's standalone. In the past couple of years, I'd say half of the problems I've had with Linux have stemmed from the fact that it shared a drive with Windows. Not that I've had an excessive number of problems, but they tended to be the sort that a novice wouldn't be able to deal with.
The way for Linux programmers to work around the new IE "features" is to pitch in and make Communicator 5.0 a better browser than IE. That way web developers won't even bother straying from the standards. Playing catchup is a good way to lose.
MS has some of the best marketing out there. And they have world domination. If you want Linux to have world domination, then it's going to have to be sold to the masses.
Besides, if MacMillan can increase the visibility and marketshare of Linux, then more Linux developers will be funded as a matter of course.
This definitely sounds like an improvement over existing Unix printing systems, but I'm not clear on whether it's going to be all that helpful on the client side.
Modern printing is more than just throwing a stream of data at a printer. When you set up printing in a Windows app, the driver lets you configure dozens of printer-specific options (paper trays, paper types, duplex, halftone settings, etc.) through a series of dialogs.
If CUPS requires a typical user to pass a bunch of command-line options to lp when he wants to run an unusual print job, then it's not going to be the least bit of help at getting Linux/Unix onto more desktops. The ability to print documents without invoking the application is nice, but hardly important to the people who do most of the printing in this world.
I haven't actually tried CUPS yet, so I may be totally off-base here. Actually, I hope I'm wrong, because printing is one of my biggest obstacles to getting Linux into non-geek environments.
Derek
Re:Matt's rant on scheduling, was Re:Exchange of i
on
CNN on Sendmail for NT
·
· Score: 1
With 5.5 you can alter folder permissions (and other properties) recursively for a whole branch by checking an option in the Exchange Administrator before you commit your changes. Accomplishing this under 5.0 was rather painful.
I support Exchange. I hate Exchange. But there is no open source software that can match its capabilities. Believe me, I've tried to put together something of the sort with the Cyrus IMAP server and OpenLDAP. The mail and directory thing is basically doable, but public folders and calendaring present problems. Even if there were a featureful free calendar server available, you'd still need to properly integrate it into the mailstore and get the client software to support it. Permission handling is also kind of messy. I would want to see ACLs on folders managed through the directory.
We do hand off outgoing mail to Sendmail before it leaves the company, so the MTA thing isn't an issue. I'm tired, though, of people claiming that Sendmail/Qmail/Postfix/etc is a complete replacement for Exchange and Outlook. Maybe if sysadmins were the only people using e-mail, but if that were the case I don't think e-mail would be particularly useful.
Unfortunately, the degree of integration that this sort of app calls for is currently best handled by a monolithic authority like Microsoft. A lot of standards have to be defined, and getting them all to work together would require a level of unity that the free software community has not exhibited so far. I hope to be proven wrong, of course, so I can get rid of these damn Exchange servers.
I think it's great that Nvidia is releasing open source drivers, and I see it as a long term advantage. That's one of the reasons I bought a TNT2 instead of a Voodoo3.
That said, there's certainly no guarantee that the TNT2 is ever going to perform better than the Voodoo3 with Mesa. If 3dfx throws more resources at their drivers, they'll probably end up being faster (even if the hardware is somewhat slower).
Open source can help produce more stable software, but there's plenty of bug-ridden free software out there. And some closed-source and in-house software is quite reliable.
Also, I think it has already been demonstrated that most users are perfectly willing to use software that isn't particularly robust.
Coincidentally, the fields with high concentrations of women and minorities usually end up being the ones with the lowest earning potential. I figure that the best way to get society to push more women into programming is to cut programmers' salaries in half.
I'm in the same position. I loathe Exchange, but don't have any simple alternatives to replace the Outlook/Exchange combination. If it were just a question of e-mail and the directory, I could drop in the Cyrus IMAP server and give users a choice of clients.
The problem is that there's a really strong case (and solid user support) for integrating calendaring and messaging. Unfortunately, Internet calendaring standards are not as mature as IMAP4 and LDAP. We haven't found a combination of open standards that will let us match that functionality.
Also, Exchange public folders are pretty handy. The back end isn't very robust, but in practice they work pretty well.
Some of our technical people are quite happy using Pine and plan. I would never force that solution on our sales force.
Most Americans (at least that I know) would like to see much stricter gun control. I guess we know different people.
I recognize the value of guns as tools of self-defense, but only against our fellow citizens (the ones with guns) and maybe the occasional rabid dog. If the government decides it wants to take you down, your guns aren't going to help you.
GPL software is largely self-documenting? If that's the case, then why is RMS so concerned about O'Reilly's "closed-source" books? O'Reilly happens to put out really good documentation on GPL software, something the FSF has never learned to do. If the freely distributable docs were any good, then nobody would buy the O'Reilly books.
Naming something after GNU is essentially the same as naming something after RMS. The two are pretty much synonymous in the public eye, and Stallman doesn't seem to have an interest in correcting that perception.
By that logic, I would argue that no OS which can be ported to a Palm Pilot could possibly be any good as a server system.
MesaGL is something like *part of* DirectX.
on
Gaming on Linux
·
· Score: 1
Mesa is comparable to Direct3D. If its performance and hardware support are improved (and I think they will be), it will be a suitable long-term replacement.
However, there are many pieces to DirectX which don't have Linux/Unix equivalents. Off the top of my head, there's DirectDraw, DirectSound, DirectPlay, DirectMusic and DirectInput. PenguinPlay attempts to match DirectX capabilities across the board, but the project is lacking in momentum these days.
The consistency is good for the developer as well. Shared components take away a lot of coding work, and allow developers to provide uniformity between applications without specifically having to plan for it. It's the same idea as using a standard widget library instead of rewriting one for every application.
I'm looking forward to seeing how the GNOME printing system turns out (I assume KDE has something similar, but I'm more familiar with GNOME). Printing under Unix is almost always a miserable kludge if you're doing anything more complicated than feeding plain text to a printer's default tray. This is one area (I'm referring to the client end, not the server end) where Windows is way ahead of Linux, and I'd like to see it resolved.
I think you're okay the way you are right now. GPL-style development is better suited to big foundation-level projects with lots of volunteers(Linux, GNOME, etc.) than to specialized niche products. Also, it's the mainstream stuff that gives proprietary software vendors their power over consumers and each other. Your company has a more direct relationship with its customers, so you're forced to actually provide a quality product with decent support.
You might, however, consider a more restrictive license along the lines of the NPL or even Sun's Community Source License. From what you've said, it sounds like the people who would be most interested in tweaking the code would be your customers. They wouldn't have any reason to resell the product (thus no competition for you), but they do have an interest in seeing it improved. If you restrict your source release to them, you could probably reap some of the benefits of open source development without facing any of the potential pitfalls.
Of course, someone could create a good GPL-alternative and run you out of business. But it would have to actually be a better product, and it's pretty unlikely at this point that anyone could muster the popular support to complete a project with such a narrow audience.
They think (not unreasonably) that Red Hat is the best investment. I understand the logic behind *working* with multiple distributions, and I applaud IBM for doing that. But when you're making an equity investment you want to do it with the company that will get you the best return for your money. At this point in time, that company is probably Red Hat.
Maybe, if several distro companies decide to go public, someone could set up a Linux mutual fund.
I think you're right on target here. If a company is developing a breakthrough piece of software in a narrow market, then they need short-term control of the market to recoup their development costs. Open development isn't an option prior to release because 1) there won't be many volunteers since there isn't much demand for the product, and 2) a small group of dedicated programmers has a better shot at breaking new ground.
Once the product takes off and becomes mainstream, the equation changes. There are now enough people who depend on it that you could realistically recruit developers for a free alternative. Also, the fundamental design of the application is already done, so bazaar-style development becomes an efficient option. The original developers have hopefully raked in a pile of profits at this point, so they will be more willing to consider a partial or complete opening of their source code. Since they've already made their name, they can continue to sell branded versions of the software and support. This could even be beneficial to the company in the long run, since it forces them to keep producing new products instead of milking what they've already created.
This is how I see proprietary software companies working peacefully with the free software community. I think, for example, that we would all like to see a quality free word processor (no, LyX doesn't count). When we have that, though, I would still be willing to pay for proprietary add-ons if they offered functionality that was useful to me. If, however, that add-on became a "must-have" feature for most users, I would like to see a free alternative developed.
One problem here: just because I have the specs for a Ford engine, doesn't mean I can build that engine to same level of quality that Ford might. With software, a copy is indistinguishable from the original. If I buy a knockoff Red Hat CD for $2, I know (objectively at least) that I'm getting the exact same code I would receive from the original vendor.
Having open software specifications isn't the same as having open *code*. I think the former is really more important, since it's necessary for products to interoperate. Open source is a good thing, but it's not the only thing. If a closed-source product gets along with my other software and has capabilities significantly greater than the free alternatives, then more power to it.
Did any sizeable number of people think of "closed-source" books about open-source software as a bad thing before RMS made that comment about O'Reilly being a "parasite"? That's only a little bit less ridiculous than the people complaining about corporations offering commercial support for Linux.
I'll reconsider the O'Reilly issue if the FSF ever manages to put out documentation remotely as good as O'Reilly books. And I'll reconsider the support issue if someone can present a realistic business plan for selling "open support".
Slashdot Mirror
There's certainly something to be said for that (thus my support for the LSB). Still, it only helps on the binary front. Source packages aren't usually focused on Solaris or BSD any more than they are on Red Hat or SuSE. Such is the price of flexibility. We're not going to see foolproof source installs unless everyone settles on one tightly-controlled *nix. That probably won't be happening in this lifetime.
I install a lot of packages this way on Solaris at work and on Linux at home. When it works it's great, but I find that it's only problem-free about 70% of the time. Quite often I need to update a shared library, hand-edit a Makefile, or tweak a line or two of C code. Not too hard for a sysadmin, but far more complicated than using an InstallShield wizard.
One big problem is that the rapid changes in the various components of the OS aren't coordinated in any real way. There's something to be said for the concept of service pack levels, even if Windows doesn't stick to it. If the underlying components can become a little more predictable (and I'm hoping that the LSB can manage this), then source distributions could be installed through a reliable, friendly interface.
Almost forgot: one other advantage of binaries is that they're a lot quicker to install. Especially on old, slow machines.
I agree that dual boot is a necessity for most people, but it's a lot easier to get a Linux install right if it's standalone. In the past couple of years, I'd say half of the problems I've had with Linux have stemmed from the fact that it shared a drive with Windows. Not that I've had an excessive number of problems, but they tended to be the sort that a novice wouldn't be able to deal with.
The way for Linux programmers to work around the new IE "features" is to pitch in and make Communicator 5.0 a better browser than IE. That way web developers won't even bother straying from the standards. Playing catchup is a good way to lose.
"...now I see it is more of a Fruitopia."
-Stephen Hawking
MS has some of the best marketing out there. And they have world domination. If you want Linux to have world domination, then it's going to have to be sold to the masses.
Besides, if MacMillan can increase the visibility and marketshare of Linux, then more Linux developers will be funded as a matter of course.
This definitely sounds like an improvement over existing Unix printing systems, but I'm not clear on whether it's going to be all that helpful on the client side.
Modern printing is more than just throwing a stream of data at a printer. When you set up printing in a Windows app, the driver lets you configure dozens of printer-specific options (paper trays, paper types, duplex, halftone settings, etc.) through a series of dialogs.
If CUPS requires a typical user to pass a bunch of command-line options to lp when he wants to run an unusual print job, then it's not going to be the least bit of help at getting Linux/Unix onto more desktops. The ability to print documents without invoking the application is nice, but hardly important to the people who do most of the printing in this world.
I haven't actually tried CUPS yet, so I may be totally off-base here. Actually, I hope I'm wrong, because printing is one of my biggest obstacles to getting Linux into non-geek environments.
Derek
With 5.5 you can alter folder permissions (and other properties) recursively for a whole branch by checking an option in the Exchange Administrator before you commit your changes. Accomplishing this under 5.0 was rather painful.
I support Exchange. I hate Exchange. But there is no open source software that can match its capabilities. Believe me, I've tried to put together something of the sort with the Cyrus IMAP server and OpenLDAP. The mail and directory thing is basically doable, but public folders and calendaring present problems. Even if there were a featureful free calendar server available, you'd still need to properly integrate it into the mailstore and get the client software to support it. Permission handling is also kind of messy. I would want to see ACLs on folders managed through the directory.
We do hand off outgoing mail to Sendmail before it leaves the company, so the MTA thing isn't an issue. I'm tired, though, of people claiming that Sendmail/Qmail/Postfix/etc is a complete replacement for Exchange and Outlook. Maybe if sysadmins were the only people using e-mail, but if that were the case I don't think e-mail would be particularly useful.
Unfortunately, the degree of integration that this sort of app calls for is currently best handled by a monolithic authority like Microsoft. A lot of standards have to be defined, and getting them all to work together would require a level of unity that the free software community has not exhibited so far. I hope to be proven wrong, of course, so I can get rid of these damn Exchange servers.
Derek
I think it's great that Nvidia is releasing open source drivers, and I see it as a long term advantage. That's one of the reasons I bought a TNT2 instead of a Voodoo3.
That said, there's certainly no guarantee that the TNT2 is ever going to perform better than the Voodoo3 with Mesa. If 3dfx throws more resources at their drivers, they'll probably end up being faster (even if the hardware is somewhat slower).
Everybody swaps some freedom for convenience. If we didn't do that, there wouldn't be anything to hold society together.
Open source can help produce more stable software, but there's plenty of bug-ridden free software out there. And some closed-source and in-house software is quite reliable.
Also, I think it has already been demonstrated that most users are perfectly willing to use software that isn't particularly robust.
Coincidentally, the fields with high concentrations of women and minorities usually end up being the ones with the lowest earning potential. I figure that the best way to get society to push more women into programming is to cut programmers' salaries in half.
I'm in the same position. I loathe Exchange, but don't have any simple alternatives to replace the Outlook/Exchange combination. If it were just a question of e-mail and the directory, I could drop in the Cyrus IMAP server and give users a choice of clients.
The problem is that there's a really strong case (and solid user support) for integrating calendaring and messaging. Unfortunately, Internet calendaring standards are not as mature as IMAP4 and LDAP. We haven't found a combination of open standards that will let us match that functionality.
Also, Exchange public folders are pretty handy. The back end isn't very robust, but in practice they work pretty well.
Some of our technical people are quite happy using Pine and plan. I would never force that solution on our sales force.
Most Americans (at least that I know) would like to see much stricter gun control. I guess we know different people.
I recognize the value of guns as tools of self-defense, but only against our fellow citizens (the ones with guns) and maybe the occasional rabid dog. If the government decides it wants to take you down, your guns aren't going to help you.
GPL software is largely self-documenting? If that's the case, then why is RMS so concerned about O'Reilly's "closed-source" books? O'Reilly happens to put out really good documentation on GPL software, something the FSF has never learned to do. If the freely distributable docs were any good, then nobody would buy the O'Reilly books.
Naming something after GNU is essentially the same as naming something after RMS. The two are pretty much synonymous in the public eye, and Stallman doesn't seem to have an interest in correcting that perception.
By that logic, I would argue that no OS which can be ported to a Palm Pilot could possibly be any good as a server system.
Mesa is comparable to Direct3D. If its performance and hardware support are improved (and I think they will be), it will be a suitable long-term replacement.
However, there are many pieces to DirectX which don't have Linux/Unix equivalents. Off the top of my head, there's DirectDraw, DirectSound, DirectPlay, DirectMusic and DirectInput. PenguinPlay attempts to match DirectX capabilities across the board, but the project is lacking in momentum these days.
The consistency is good for the developer as well. Shared components take away a lot of coding work, and allow developers to provide uniformity between applications without specifically having to plan for it. It's the same idea as using a standard widget library instead of rewriting one for every application.
I'm looking forward to seeing how the GNOME printing system turns out (I assume KDE has something similar, but I'm more familiar with GNOME). Printing under Unix is almost always a miserable kludge if you're doing anything more complicated than feeding plain text to a printer's default tray. This is one area (I'm referring to the client end, not the server end) where Windows is way ahead of Linux, and I'd like to see it resolved.
To most Americans who have heard both of them speak, RMS seems a lot more foreign than Linus.
I think you're okay the way you are right now. GPL-style development is better suited to big foundation-level projects with lots of volunteers(Linux, GNOME, etc.) than to specialized niche products. Also, it's the mainstream stuff that gives proprietary software vendors their power over consumers and each other. Your company has a more direct relationship with its customers, so you're forced to actually provide a quality product with decent support.
You might, however, consider a more restrictive license along the lines of the NPL or even Sun's Community Source License. From what you've said, it sounds like the people who would be most interested in tweaking the code would be your customers. They wouldn't have any reason to resell the product (thus no competition for you), but they do have an interest in seeing it improved. If you restrict your source release to them, you could probably reap some of the benefits of open source development without facing any of the potential pitfalls.
Of course, someone could create a good GPL-alternative and run you out of business. But it would have to actually be a better product, and it's pretty unlikely at this point that anyone could muster the popular support to complete a project with such a narrow audience.
They think (not unreasonably) that Red Hat is the best investment. I understand the logic behind *working* with multiple distributions, and I applaud IBM for doing that. But when you're making an equity investment you want to do it with the company that will get you the best return for your money. At this point in time, that company is probably Red Hat.
Maybe, if several distro companies decide to go public, someone could set up a Linux mutual fund.
I think you're right on target here. If a company is developing a breakthrough piece of software in a narrow market, then they need short-term control of the market to recoup their development costs. Open development isn't an option prior to release because 1) there won't be many volunteers since there isn't much demand for the product, and 2) a small group of dedicated programmers has a better shot at breaking new ground.
Once the product takes off and becomes mainstream, the equation changes. There are now enough people who depend on it that you could realistically recruit developers for a free alternative. Also, the fundamental design of the application is already done, so bazaar-style development becomes an efficient option. The original developers have hopefully raked in a pile of profits at this point, so they will be more willing to consider a partial or complete opening of their source code. Since they've already made their name, they can continue to sell branded versions of the software and support. This could even be beneficial to the company in the long run, since it forces them to keep producing new products instead of milking what they've already created.
This is how I see proprietary software companies working peacefully with the free software community. I think, for example, that we would all like to see a quality free word processor (no, LyX doesn't count). When we have that, though, I would still be willing to pay for proprietary add-ons if they offered functionality that was useful to me. If, however, that add-on became a "must-have" feature for most users, I would like to see a free alternative developed.
One problem here: just because I have the specs for a Ford engine, doesn't mean I can build that engine to same level of quality that Ford might. With software, a copy is indistinguishable from the original. If I buy a knockoff Red Hat CD for $2, I know (objectively at least) that I'm getting the exact same code I would receive from the original vendor.
Having open software specifications isn't the same as having open *code*. I think the former is really more important, since it's necessary for products to interoperate. Open source is a good thing, but it's not the only thing. If a closed-source product gets along with my other software and has capabilities significantly greater than the free alternatives, then more power to it.
Did any sizeable number of people think of "closed-source" books about open-source software as a bad thing before RMS made that comment about O'Reilly being a "parasite"? That's only a little bit less ridiculous than the people complaining about corporations offering commercial support for Linux.
I'll reconsider the O'Reilly issue if the FSF ever manages to put out documentation remotely as good as O'Reilly books. And I'll reconsider the support issue if someone can present a realistic business plan for selling "open support".