The moral of this story is that installing software on any flavor of Linux is still a royal pain...
That's a very general moral. I expect it's more that installing the software you tried to install on the machines you use running the distributions you run was painful.
They hire professional writers, actors, directors, lighters, camera operators, assistants, set designers, costumers, makeup artists, and effects workers. Why should it take them all a year to produce something worthwhile? They're professionals. They should already be decent at what they do.
If this were a completely new genre or if they had completely unknown actors, writers, and workers, or if they had no budget, it might be easier to accept a year of low quality. However, Paramount should have some idea of what it's doing with a flagship franchise on its fifth or sixth incarnation.
64-bit? 32-bit? With debugging symbols? Without debugging symbols? Statically-linked? Dynamically linked? Which level of optimization? Which kernel? Which compiler? Which glibc? Which processor family? Which instruction set within a processor family? What options have I missed?
How big is this one self-installing binary you want someone else to create for you?
Please don't republish copyrighted material without permission. We have a nice web cluster and plenty of bandwidth. We handle several referrals from Slashdot every month.
It's funnier than that. A couple of months after HP sold off its internal network to an agency, it started advertising professional services to manage networks for other companies.
It worked that way in HP at Boise before the merger, too.
HP recruited new workers through contract work, dismissed people they didn't want to keep early hired the ones they did want to keep early, and let the two year contracts run out for the ones the wanted to fill positions. Becoming a full-time employee represented a substantial pay raise and much better benefits.
I disclaim the question. What part of natural language (especially English) is "intuitive"?
Still, see perldoc perlvar. Every special variable has a mnemonic and an optional extended name, if you use the English module. For $|, it's "when you want your pipes to be piping hot".
I know that if you modify open source software you HAVE to redistribute it to the open source community.
No, you don't. You have no obligation to distribute your modified version of the code to anyone just because you've modified it. You can modify it and keep it to yourself. If you do distribute a binary of your modified version, you do have the obligation under the GPL to make your modified source code available, also under the GPL, to everyone to whom you distribute the binary.
Can you still sell your product w/ the open-source DB packaged in??
Yes. The GPL does not prevent you from selling anything. The interaction of the license of the database and the GPL as well the way your code interacts with the database may open or close some options for what you can do with the binaries and the source when you distribute either, but you'll have to ask a more specific question to receive a better answer.
Ah, I see our differences now. My experience is in building software for specific clients. Yours sounds closer to off-the-shelf software.
I suspect that having greater knowledge of what your target market wants and needs will be helpful, which is similar to what you said earlier. You're right; if you don't have a clear customer capable of identifying and prioritizing actual business needs for the software, XP's planning features won't work very well.
...those costs are also much greater than the cost of doing the up-front analysis.
Only as far as the business requirements do not change after the analysis or the initial analysis anticipates changes in business requirements accurately.
That's possible, but I've never seen it happen.
Incremental requirements analysis coupled tightly to incremental development leads to hodgepodge systems unless the developers are really given free rein to refactor on a whim.
Indeed; that's exactly what XP suggests!
In a situation where I had complete, sufficient, and accurate specifications up front, I'd still use most of XP: frequent iterations, customer prioritization, test-driven development, and heavy refactoring. I haven't seen anything else reduce my bug counts or improve my code's maintainability and efficacy as dramatically.
With any method you pick, as everyone knows, the later in the project you make changes the more they cost. They always leave off that part.
The fundamental premise of XP is that there are ways to reduce those costs dramatically. A secondary premise is that exposing the costs of those changes at the point of change gives stakeholders more information to evaluate the necessity of those changes.
...just because something is deemed a "release" doesn't endow it with magical powers of stability.
Of course not! However, making something stable enough that you can honestly deem it release-worthy tends to attract packagers, users, and ultimately developers. It's also really good pressure to keep the code buildable, installable, and passing its test suite.
Helpful tip: avoid the breakfast cereal aisle of any supermarket in the U.S., lest the bewildering array of choices and your own indecision cause you to starve.
These steps are not hard, and provide for stellar enterprise management capabilities.
I find it difficult to believe that many home users want "stellar enterprise management capabilities", but you did quite well at redefining the question!
If you used the errata form on the book's catalog page, your report went into a request tracking system which sends mail to the editor and the author. From there, both can suggest changes or corrections to make in the next printing or edition. When the next printing or edition comes due, the editor receives an automated message asking for a collection of changes -- conveniently tracked in the request tracker.
As far as I've seen, the system works. None of the books I've edited have gone in for reprint yet though.
You'd be liable even if you didn't know about it. The terrible part is that if you knew about the infringements, you'd be liable for triple damages. See my article Linux and Patent Risks, for example.
Slashdot Mirror
That's a very general moral. I expect it's more that installing the software you tried to install on the machines you use running the distributions you run was painful.
They hire professional writers, actors, directors, lighters, camera operators, assistants, set designers, costumers, makeup artists, and effects workers. Why should it take them all a year to produce something worthwhile? They're professionals. They should already be decent at what they do.
If this were a completely new genre or if they had completely unknown actors, writers, and workers, or if they had no budget, it might be easier to accept a year of low quality. However, Paramount should have some idea of what it's doing with a flagship franchise on its fifth or sixth incarnation.
Is it simple or obvious?
64-bit? 32-bit? With debugging symbols? Without debugging symbols? Statically-linked? Dynamically linked? Which level of optimization? Which kernel? Which compiler? Which glibc? Which processor family? Which instruction set within a processor family? What options have I missed?
How big is this one self-installing binary you want someone else to create for you?
Please don't republish copyrighted material without permission. We have a nice web cluster and plenty of bandwidth. We handle several referrals from Slashdot every month.
It's funnier than that. A couple of months after HP sold off its internal network to an agency, it started advertising professional services to manage networks for other companies.
It worked that way in HP at Boise before the merger, too.
HP recruited new workers through contract work, dismissed people they didn't want to keep early hired the ones they did want to keep early, and let the two year contracts run out for the ones the wanted to fill positions. Becoming a full-time employee represented a substantial pay raise and much better benefits.
The infringer could also stop distributing modified versions.
It may seem odd, but Pugs has actually inspired several developers to learn Haskell.
I disclaim the question. What part of natural language (especially English) is "intuitive"?
Still, see perldoc perlvar. Every special variable has a mnemonic and an optional extended name, if you use the English module. For $|, it's "when you want your pipes to be piping hot".
No, you don't. You have no obligation to distribute your modified version of the code to anyone just because you've modified it. You can modify it and keep it to yourself. If you do distribute a binary of your modified version, you do have the obligation under the GPL to make your modified source code available, also under the GPL, to everyone to whom you distribute the binary.
Yes. The GPL does not prevent you from selling anything. The interaction of the license of the database and the GPL as well the way your code interacts with the database may open or close some options for what you can do with the binaries and the source when you distribute either, but you'll have to ask a more specific question to receive a better answer.
I was going to mention Sophocles, but then I re-read your word sympathetic.
Ah, I see our differences now. My experience is in building software for specific clients. Yours sounds closer to off-the-shelf software.
I suspect that having greater knowledge of what your target market wants and needs will be helpful, which is similar to what you said earlier. You're right; if you don't have a clear customer capable of identifying and prioritizing actual business needs for the software, XP's planning features won't work very well.
Only as far as the business requirements do not change after the analysis or the initial analysis anticipates changes in business requirements accurately.
That's possible, but I've never seen it happen.
Indeed; that's exactly what XP suggests!
In a situation where I had complete, sufficient, and accurate specifications up front, I'd still use most of XP: frequent iterations, customer prioritization, test-driven development, and heavy refactoring. I haven't seen anything else reduce my bug counts or improve my code's maintainability and efficacy as dramatically.
The fundamental premise of XP is that there are ways to reduce those costs dramatically. A secondary premise is that exposing the costs of those changes at the point of change gives stakeholders more information to evaluate the necessity of those changes.
Of course not! However, making something stable enough that you can honestly deem it release-worthy tends to attract packagers, users, and ultimately developers. It's also really good pressure to keep the code buildable, installable, and passing its test suite.
I'm not sure. The difficulties he has had in maintaining his code (or writing maintainable code) argue otherwise.
Maybe he'll deliver something amazing; I don't know. I lost faith in his development process a long time ago, though.
Helpful tip: avoid the breakfast cereal aisle of any supermarket in the U.S., lest the bewildering array of choices and your own indecision cause you to starve.
I find it difficult to believe that many home users want "stellar enterprise management capabilities", but you did quite well at redefining the question!
If you used the errata form on the book's catalog page, your report went into a request tracking system which sends mail to the editor and the author. From there, both can suggest changes or corrections to make in the next printing or edition. When the next printing or edition comes due, the editor receives an automated message asking for a collection of changes -- conveniently tracked in the request tracker.
As far as I've seen, the system works. None of the books I've edited have gone in for reprint yet though.
Ahh, I'd always wondered how Riker and Troi met.
R is just a P with a moustache.
You'd be liable even if you didn't know about it. The terrible part is that if you knew about the infringements, you'd be liable for triple damages. See my article Linux and Patent Risks, for example.
That was a popular article. See IE Shines on Broken Code.
Wow, Windows 2000 and Windows XP? Nifty.
By what mechanism can you duplicate food indefinitely at almost no cost?
If you can do so, by what right can you withhold a limitless supply of food from starving people?