Ever played "Elder Scrolls 3: Morrowind"? On my machine, it will BSOD unpredictably several times a day, only when running this game. Freshly built machine, fully patched, current drivers.
I know what you're thinking. It's the app, not the OS. Yes, it's the app that crashes - but an application should not be capable of taking down the whole machine, and that's a fault of the OS.
One of my biggest pet peeves with open source software is what I call the CVS cop-out. It works like this: I criticize (accurately) some shortcoming of an open source application either in an article or in conversation, and someone responds with, "That's not true! That feature was fixed in CVS four weeks ago!"
This is certainly a legitimate beef - and deserves a diplomatic response. As TFA article states, saying it's in CVS isn't a useful answer to the end user.
IYou really have to have blinders on to think that a patch in the revision control system marks the end of the issue. The majority of Linux and open source users get their software in pre-compiled binaries, and not from CVS, SVN, or any of the alternatives.
Certainly it doesn't make the end of the issue. For the developers, the issue isn't resolved until the patch is rolled into a stable release and made available downstream. For the distro maintainers / binary providers, it's not resolved until the release is integrated, tested, and released to the end user community.
But certainly it is better to publicly maintain a downloadable, alpha-and-beta-testable "development" branch than it is to leave users out in the cold. Between the two alternatives, giving the mass market access to unstable code with recent fixes is surely preferable to the CVS cop-out.
I understand your point here - but the fact is that the vast majority of end users (who as you said run whatever pre-compiled binaries are included with thier distro) aren't going to have a clue how to obtain source from CVS, deal with any dependancies, and get it compiled and running. If you were a developer, would you want to deal with the deluge of questions and issues surrounding getting bleeding edge code up and running? I am, and I don't.
What justification is there for ignoring the long-standing tradition of "release early, release often?" Too many bug reports? Users are the lifeblood of an open source project, and bug reports are the white blood cells. Even when there are dupes, they're a good thing.
There's a fine line here. I'm a fan of frequent and regular releases. But I'm also a fan of releasing adequately tested code to the end user. Short release cycles are an option for projects which are not too complex, have adequate staffing and/or funding, amongst other things. To borrow from your Rhythmbox example - and the example bug that prevented play of m4b files: this is, IMHO, not an example that rapid release would fix, in fact, this is more likely a case where code was release without sufficient integration testing. I don't know the details of this particular scenario, but it stands to reason that as you said, a package that has 50+ dependancies on external libraries isn't going to necessarily get upstream fixes integrated quickly. There may be other issues at play here (e.g. design issues, unstable APIs, insufficient developer resources, etc.).
In short, rapid release is a good thing, if the project can support it. Many can't.
In this case, the fix is probably not to roll forward to bleeding edge CVS, it's to roll back to a previous known good release.
There is no simple solution to this issue. As both a user and a developer, it's frustrating.
I hear what you're saying, and it may apply to the shrink-wrap software business. I don't know, I've never had any interest in working that particular part of the industry. I work as part of a team that delivers custom integration solutions, and everything here is driven by sales, marketing, and the customer's timeline. Time-to-market is everything: we promise to deliver on the customer's scheduler, or the customer goes elsewhere, and if we don't make that promise, someone else will. Oh sure, they may say that a project is cost-driven, or quality-driven, but that fact is this: everything comes down to time-to-market.
I don't like it, nor do I wish to defend the practice. But the reality of the situation is this - we have a small number of very big customers. If we don't deliver on the promised schedule, we risk losing customers, and therefore a large part of our revenue stream - and that revenue is ultimately what pays my mortgage, puts shoes on my kid's feet, and puts food on my table.
But yeah, with those factors out of consideration, I'd agree that the commercial software development model is broken.
In reality, every place I've worked the last 15 years, Sales and Marketing has a hell of a lot more to do with release dates than the level of effort / resource constraints given by our engineering group. Dates are promised before we've even heard that a project exists - and to make it fit within the promised date, guess what suffers? In the rare case where they *do* ask us for a date, we're always told "that's not soon enough, you'll have to make it fit by [insert date]".
The worst part of it is that the dates are almost always concocted out of thin air, with no real NEED to meet.
If an message doesn't get through because there's a problem with the recipient systems, then I want to know about it. The fact that emails can be silently lost is a major flaw in its design.
No, it isn't. The fact that emails can be silently lost is a flaw in implementation and/or configuration, not in the design of the system (i.e. the SMTP protocol). In other words, it's the fault of the people running the system, not the system itself, and not those that designed it.
I design and write software related to the reliable exchange of messages between hetrogenous systems for a living. Not email, but in a former life, I was sole administrator for a large organization's email system (thousands of users).
Email delivery is based upon a store-and-forward delivery model - in terms of reliability, this is the most appropriate model for the medium. I won't bother to explain why, you'll have to accept that statement as fact, or not.
In a perfect world, SMTP delivery of mail is 100% reliable:
1) The orginating client (Sender) transmits the message to an mail transmission agent (MTA, or "mail server" to PHBs), which accepts it, and queues it for delivery. If this exchange fails, an error is returned to the client, in which case, no delivery occurred, and presumably, the client has stored the message for later retransmission.
2) If the first MTA is not the delivery destination, the message will be forwarded to another (intermediary) MTA. If this delivery fails, the message queued again for later retransmission. If the message can't be delivered within a specified interval (defined at the whim of the administrator), the message is returned to the sender as a non-delivery notification (NDN), or delivery status notification (DSN).
The message may travel between many intermediary MTAs before arriving at the final delivery MTA.
3) Once the message arrives at the delivery MTA (i.e. the one configured to accept delivery of messages for user@domain.com), the message is stored for the recipient's client to pick up. If this delivery fails, a NDN/DSN is sent to the original sender.
4) The client connects to its mail server, and picks up the message using IMAP / POP / Exchange, etc. If this transfer fails, the message should be retained on the server for later pickup.
In this perfect work, at each step in the delivery process, there is no opportunity for mail to be "silently lost" without notification.
We don't live in that perfect world, however.
Administrators may (mis?)configure thier systems, and programmers may code to not return NDN / DSN.
Administrators may configure thier systems, and programmers may code to lie about the delivery status of a message.
Disks die, and when they do, they may (unknowingly to any software), take your carefully crafted email with it.
Administrators may accidently (or intentionally) remove your mail from a queue before it can be delivered.
The recipient may have configured his client to forward your message to another desination instead of storing it locally. Has such a message been truly delivered?
None of this is known, or can be known, in a store-and-forward system. Your only assurance of final delivery is, and can only be, if the recipient chooses to notify you via response to a return receipt request or by responding to the message.
Slashdot Mirror
Ever played "Elder Scrolls 3: Morrowind"? On my machine, it will BSOD unpredictably several times a day, only when running this game. Freshly built machine, fully patched, current drivers. I know what you're thinking. It's the app, not the OS. Yes, it's the app that crashes - but an application should not be capable of taking down the whole machine, and that's a fault of the OS.
I'll take fifty cases.
From TFA
One of my biggest pet peeves with open source software is what I call the CVS cop-out. It works like this: I criticize (accurately) some shortcoming of an open source application either in an article or in conversation, and someone responds with, "That's not true! That feature was fixed in CVS four weeks ago!"
This is certainly a legitimate beef - and deserves a diplomatic response. As TFA article states, saying it's in CVS isn't a useful answer to the end user.
IYou really have to have blinders on to think that a patch in the revision control system marks the end of the issue. The majority of Linux and open source users get their software in pre-compiled binaries, and not from CVS, SVN, or any of the alternatives.
Certainly it doesn't make the end of the issue. For the developers, the issue isn't resolved until the patch is rolled into a stable release and made available downstream. For the distro maintainers / binary providers, it's not resolved until the release is integrated, tested, and released to the end user community.
But certainly it is better to publicly maintain a downloadable, alpha-and-beta-testable "development" branch than it is to leave users out in the cold. Between the two alternatives, giving the mass market access to unstable code with recent fixes is surely preferable to the CVS cop-out.
I understand your point here - but the fact is that the vast majority of end users (who as you said run whatever pre-compiled binaries are included with thier distro) aren't going to have a clue how to obtain source from CVS, deal with any dependancies, and get it compiled and running. If you were a developer, would you want to deal with the deluge of questions and issues surrounding getting bleeding edge code up and running? I am, and I don't.
What justification is there for ignoring the long-standing tradition of "release early, release often?" Too many bug reports? Users are the lifeblood of an open source project, and bug reports are the white blood cells. Even when there are dupes, they're a good thing.
There's a fine line here. I'm a fan of frequent and regular releases. But I'm also a fan of releasing adequately tested code to the end user. Short release cycles are an option for projects which are not too complex, have adequate staffing and/or funding, amongst other things. To borrow from your Rhythmbox example - and the example bug that prevented play of m4b files: this is, IMHO, not an example that rapid release would fix, in fact, this is more likely a case where code was release without sufficient integration testing. I don't know the details of this particular scenario, but it stands to reason that as you said, a package that has 50+ dependancies on external libraries isn't going to necessarily get upstream fixes integrated quickly. There may be other issues at play here (e.g. design issues, unstable APIs, insufficient developer resources, etc.).
In short, rapid release is a good thing, if the project can support it. Many can't.
In this case, the fix is probably not to roll forward to bleeding edge CVS, it's to roll back to a previous known good release.
There is no simple solution to this issue. As both a user and a developer, it's frustrating.
I hear what you're saying, and it may apply to the shrink-wrap software business. I don't know, I've never had any interest in working that particular part of the industry. I work as part of a team that delivers custom integration solutions, and everything here is driven by sales, marketing, and the customer's timeline. Time-to-market is everything: we promise to deliver on the customer's scheduler, or the customer goes elsewhere, and if we don't make that promise, someone else will. Oh sure, they may say that a project is cost-driven, or quality-driven, but that fact is this: everything comes down to time-to-market.
I don't like it, nor do I wish to defend the practice. But the reality of the situation is this - we have a small number of very big customers. If we don't deliver on the promised schedule, we risk losing customers, and therefore a large part of our revenue stream - and that revenue is ultimately what pays my mortgage, puts shoes on my kid's feet, and puts food on my table.
But yeah, with those factors out of consideration, I'd agree that the commercial software development model is broken.
In theory, what you're saying makes sense.
In reality, every place I've worked the last 15 years, Sales and Marketing has a hell of a lot more to do with release dates than the level of effort / resource constraints given by our engineering group. Dates are promised before we've even heard that a project exists - and to make it fit within the promised date, guess what suffers? In the rare case where they *do* ask us for a date, we're always told "that's not soon enough, you'll have to make it fit by [insert date]".
The worst part of it is that the dates are almost always concocted out of thin air, with no real NEED to meet.
- Administrators may (mis?)configure thier systems, and programmers may code to not return NDN / DSN.
- Administrators may configure thier systems, and programmers may code to lie about the delivery status of a message.
- Disks die, and when they do, they may (unknowingly to any software), take your carefully crafted email with it.
- Administrators may accidently (or intentionally) remove your mail from a queue before it can be delivered.
- The recipient may have configured his client to forward your message to another desination instead of storing it locally. Has such a message been truly delivered?
None of this is known, or can be known, in a store-and-forward system. Your only assurance of final delivery is, and can only be, if the recipient chooses to notify you via response to a return receipt request or by responding to the message.