|
in reply to blaming perl for not using a build policy
There is a long history in the commercial 'NIX world of compilers and other tools being abominable. It's no different than any other commercial software endeavor, and popularity is no guarantee. A good example that come to mind is the C compiler that shipped with HP-UX right up until the end of the twentieth century, which was so bad as to be mostly unusable. Another is that Solaris until recently shipped with a very early Perl (5.003, IIRC). (I have a friend at SNL who is STILL dealing with some of these old monstrosities. He's not likely to be allowed to retire.)
The very nature of the true freeware community is that SOMEBODY's going to want something to work on at three in the morning, and that's why GNU 'ls' has forty-'leven options and most of them work the way they're intended to. The very nature of he commercial world, and that includes Red Hat, is that you freeze it and get it out the door. To say the commercial world should be otherwise is like saying that rocks should fly.
I wholeheartedly agree that anybody doing production work of any kind for commercial purposes MUST be prepared to investigate, understand, and validate their tools, all the way down to the raw os. And yes, I've also been known to run acid tests on even generic PC motherboards. You'd be surprised what crap gets out there into the field, especially when you're trying to bleed the edge. You have to be prepared to take a trip out to the back of the sausage factory, and you can't just spill your cookies after you do so.
Even when you stand on the shoulders of giants, you must be prepared to find out which way they're headed. YMMV isn't just a saying, it's an expectation that comes with the territory. It's your responsibility to use wealth wisely, be it FOSS or payware or something in-between.
Don Wilde
"There's more than one level to any answer."
|
Re^2: blaming perl for not using a build policy
by shmem (Chancellor) on Aug 26, 2008 at 16:35 UTC
|
A good example that come to mind is the C compiler that shipped with HP-UX right up until the end of the twentieth century, which was so bad as to be mostly unusable.
Yeah, and their broken vi. Solaris has issues, too; that's right. But those UNIX vendors have a tight license policy, and
while they all have roots in good ol' Berkeley, their software is closed source.
RedHat, on the other hand, and more Fedora, build their distributions on open source - to the extent that they exclude
stuff ruled by software patents, like mpeg encoding - for anyone to look at, test, and provide a fix at three o'clock in the morning.
The only commercial aspect of their's is testing, packaging, distribution and commercial support for what they call
"Enterprise" (well, certification of their distros too, for closed source stuff like oracle and SAP). They should, for the sake of their reason to be, get that right - and heed the open source community to get it right. The perl fixes are out there for some time now.
| [reply] |
|
|
| [reply] |
Re^2: blaming perl for not using a build policy
by blazar (Canon) on Aug 27, 2008 at 12:28 UTC
|
The very nature of the true freeware community is that SOMEBODY's going to want something to work on at three in the morning, [...] The very nature of he commercial world, and that includes Red Hat, is that you freeze it and get it out the door. To say the commercial world should be otherwise is like saying that rocks should fly. [...] It's your responsibility to use wealth wisely, be it FOSS or payware or something in-between.
(Additional emphasis by me.)
I personally believe that you're making a big confusion between freeware, which is not free software and open source software which is a development model and needs not be freeware nor free software. You're also making confusion between commercial software and (implicitly) proprietary software, whereas the former can actually be free software, just as much as freeware can be at the same time proprietary, and often is!
I'm also all with you in supporting gratis, free and OS software, and somehow deprecating commercial, proprietary software, but yours is far too drastic a generalization: some would argue that a developer, or a software house in the second category, depending on people paying for the quality of their products, will have someone having "to work on your problem at three in the morning." OTOH you certainly know that there are tons of freeware, free software and open source projects which are not developed any more because of lack of interest from the original developers or some other reason.
| [reply]
[d/l] |
|
|
| [reply] |
Re^2: blaming perl for not using a build policy
by JavaFan (Canon) on Aug 27, 2008 at 14:37 UTC
|
There is a long history in the commercial 'NIX world of compilers and other tools being abominable
Partially true. For instance, many vendors ship a free (C) compiler (or make a free compiler available for download), which tend to not be very good. However, give me a commercial, paid-for, C compiler anytime. It tends to build faster binaries than gcc (which doesn't mean gcc is bad, not at all, but gcc targets a wide range of platforms, and its developers usually don't have the same intimitate knowledge of the OS as the commercial vendor does). I've build perl with both commercial compilers and gcc on the same platform, and most of the time, perl build with a commercial compiler was faster in my tests (although never more than 25%).
Another is that Solaris until recently shipped with a very early Perl (5.003, IIRC).
Not my experience at all. AFAIR, Solaris went from a "no perl" policy to "whatever is newest when the Solaris code freeze happens". Alan Burlison was always pretty keen to have the newest Perl included, although I don't think he's involved in that process anymore. | [reply] |
|
|
| [reply] |
|
|
