...IMHO, can be found in the following single line from The Fine Article:
But after nearly 15 years in use, the business had grown accustomed to the SBS system, and much of Comair's crew management business processes had grown directly out of it.
(emphasis added)
Talk about putting the cart in front of the horse. This system would never have been replaced before it's crash--the cost of readjusting process and any other attached technology would have dwarfed simply updating the software. There was no business case you could make that would appear to justify the expense. Other than the little matter of "your company won't function if something goes wrong", of course...
Also, you'd never find a decent replacement product--since it's functionality would have to mirror those same system-driven business processes.
The truly major oversight was in letting the package drive how Comair did this part of it's business in the first place. Done otherwise, the meltdown might still have happened, for plenty of reasons outlined in the article. But left this way, this result was pre-ordained. No amount of planning or "risk assessment" was going to counter the inertia created by this process/technology inversion.
IIRC, OS/2 (at least Warp) shipped with a complete install of MS-Win to provide dual-OS support. The OS/2 code contained lots of integration points--if these integration points relied on Win code provided as part of the infamous "divorce decree", that would presumably be off-limits without MS's blessing. If so, would there be enough "untainted" OS/2 code left to be useful as open source?
I didn't use later versions of OS/2, so I don't know if this chimera-like architecture was changed further on...
Not that any book can cover every useful J2EE tool out there...but leaving XDoclet out, particularly in a book aimed at improving J2EE development time, would be a baffling omission.
I've worked with most of the other tools mentioned in the review and they're all good. But nothing helped speed my own J2EE work more than XDoclet, particularly with EJB's and all their interface definitions, configuration files and container-specific instruction files.
Maybe with some periodicals, but with the WSJ...no thanks. 60+ pages daily, full sheet, financial summaries in agate type--good luck navigating that much content with a PDA, no matter how well it's designed.
It could also be used to protect themselves from a variety of possible legal concerns that might arise from their normal operations.
I work with content and content management systems and see similar clauses in most of our contracts with subject matter experts, authors and provisioning contractors. I'm not a lawyer myself, but have asked our legal staff about why these are included, and the consensus answer I get from them is that they save considerable legal effort dealing with the spiderweb of regulations, laws and statutes encountered when trying to distribute content to users in multiple countries. To paraphrase them, it's essentially a "get out of jail free" card for most common issues of redistribution problems our company might encounter.
Comments from actual lawyers (if any are lurking) would be helpful.
It certainly could be abused, but that's not the first purpose I'd think of.
And maybe we realize that "the idiot is *not* always right". In fact, when the average user knows very little about software in general.
Might be so, but they generally have at least a dim idea of what they want to accomplish with that software. Whatever else your software does well, if it raises too many stumbling blocks between those "idiots" and what they ultimately want to accomplish with it, you'll have a pretty small user group and you'll miss the occasional opportunity to learn how to effectively provide some useful service to those folks, alongside whatever you actually are trying to accomplish yourself.
God forbid, the illiterate idiots might actually have something worth hearing once in awhile...
Claiming tortious interference with an existing business relationship, General Mills has filed suit to block the MS-Chocula deal.
"The Count has been an integral part of our GM team for 34 years. Any money sucking he will be doing will be into General Mills' coffers, not some two-bit meat packing company", apparently referring to the upcoming Longhorn release of Microsoft's flagship product. "We look forward to maintaining the productive relationship between the Count and worldwide youth for many years to come.", according to an unsigned press release from General Mills.
Microsoft spokespeople had no official comment on the suit. Well-connected individuals, speaking anonymously, claimed that a contingency plan, seeking to enlist the services of Count Dracula, has already been put into effect, claiming "Microsoft can make do with pretty much any kind of sucker." One snag in the plan has been the inability of the Count's legal and marketing representatives to make contact with their client, as his last known address has been the subject of considerable debate.
I will say this one more time, since the reply apparently didn't register with you: I am not asking "Slashdotters" for anything, requiring dev. psych comprehension or not. I'm asking the original poster how his/her brother is impaired. What is so fricking hard to comprehend about this?
I would like to help the poster. I don't want to waste their time. The original poster was using quasi-technical language describing an impairment level; I would reasonably presume he/she wouldn't just be pulling that out of their rear. That "correct technical language" is important in identifying what has been observed to be effective with other similar patients. Do you seriously believe this to be pointless?
I think this is enough on this thread already. Hopefully the poster found something useful, or will be willing to provide some more detail for those of us who would like to help him/her. As for you...spend your time suggesting something useful for the poster's sibling, if you're aware of something helpful.
"He can't read or write very well" is a perfectly adequate description.
Perfectly adequate if you want to toss a dart at the neurological dartboard and hope it hits something useful. I suspect the original poster is hoping for something a bit more precise. I would also presume that said poster would probably have a good idea of a diagnosis if his brother's impairment was observed as long ago as his post indicates.
I listed 5 separate potential barriers to learning, several with a pronounced physiological components, several of uncertain origin. These just scratch the surface of observed neuropathology. Each will respond differently to various stimuli including reactive response and short/long term memory transfer, two important components in defining the phenomenon we call "learning". I would hope that the poster would not want his/her time wasted, if a bit of information could help separate useful answers from useless answers.
I would also add that each of the above (with the possible exception of PDD, being fairly new to the DSM) have a quantitative components as part of their diagnostic criteria. Whatever your apparently poor opinion of DSM diagnostic screening may stem from, they're not completely subjective.
Or perhaps you'd prefer to start from scratch with every patient that presents with difficulty recalling and utilizing language and numerical symbology. Your choice, I guess. Be prepared for a very long pre-diagnostic experience. And be a big believer in "lucky guessing".
What is the nature of your brother's disability? PDD? DS? Kanner's autism? Dyslexia? CHI? What defines "effective" software is going to vary considerably based on the diagnosis...
(writing with a very general, not expert, knowledge of how BT works...)
I'm familiar with BT mirroring. I don't dispute that the mirroring would work fine, technically. The problem in this case is business--with mirroring on anything other than a "officially" managed site, in this case, is that this model officially becomes DOA from the advertisers' perspective. If someone in Fandom could conceivably be spawning the actual episode content, how would you know to count them, from a demographic point of view? And without that counting, no ad client is going to pay more than chicken feed to buy slots--from their perspective, those ad buys would be little more than speculation. Throwing an ad out and hoping that someone actually sees it, without having any way of even guestimating viewership. Given the general lack of confidence in the current system (in the US, at least), that wouldn't be an easy sell.
So you either pay through the nose to host, or you surrender most of your potential ad revenue by allowing other people to mirror. Where's the win for the studios?
Now, if you could come up with some way of having the viewer identified to the agency when viewing the episode, that's potentially workable. Maybe there's some magic that would allow this in the BT archtecture. Without it, though, you'd have to go on the assumption that the studio shoulders the whole load.
Like I said originally, it's an interesting idea. I'd love it myself and would probably use it. Just come up with a way to keep the ad buyers comfortable that their money is actually accomplishing something.
Flash back to 1982 (and, yes, I'm old enough to actually remember 1982): you could take the above post verbatim, replace every instance of "China" with "Japan" and quite a few people would probably agree with it.
How would they incur "substantial" costs for storage and transmission bandwidth using bittorrent? Currently these shows are being seeded by people with cable modems to THOUSANDS of people at the same time.
The original poster's plan would require One True Torrent site, run by the studio, to source the episodes. The studio wouldn't be able to rely on Fandom to mirror content and thereby spread the storage/bandwidth costs around.
Further, said "official" site would be responsible for serving massive content streams to hundreds of thousands, if not millions of individuals weekly.
Big-time money needed. Every ISP on the planet would be licking it's chops at the thought of putting a meter on this.
Interesting idea. You'd have a "official" BT site for series episodes (necessary so that ad buyers could verify actual download counts).
Potential snag: you'd be adding potentially substantial costs for storage and transmission bandwidth to the existing cost of production.
How do you subsidize these costs assuming...
1. You probably won't be able to up slot costs significantly. Even allowing for the attraction of more solid view counts, why would an agency spend more money buying slots here when the same content would reach more people for less money over the air?
2. Networks will not accept any degradation of profit margins for the show.
so all the people who do observe it are dragging you down with them.
Never, I say! It's bad enough that the whole Cristianity thing was founded by a nice Jewish boy gone renegade. Now I have to get dragged down by their stinking holiday as well? Ptah.
And, while we're on the topic of holidays, if Dr. Arnalls thinks that Christmas is the best he can do for emotional nadirs, then he doesn't know bubkes about bad. You want bad? Try any one of my faith's holidays. Every single one of them is predicated on remembering some group's attempt to completely eradicate us. Even bleeping Hannukah. Festival of Joy, indeed.
And don't get me started on what a merry day Yom Kippur is...
Thanks for the reply. I disagree with the need to dump the OO codebase. UI issues notwithstanding (since Apple would be re-writing much of the UI as a port anyway), the majority of the document manipulation, storage and formatting functions in OO are independent of the UI. It's this work that I would prefer Apple leverage rather than re-invent.
Don't get me wrong: the UI would be a huge task. But I don't think Apple is going to save any time by having both UI and document engine tasks on their to-do lists.
Regarding speed and memory size--obviously those items are in the "YMMV" group. Speed is and was a potential issue--we'll see how it works with 2.0 final. Memory...I don't know. It does use a lot. That might make a difference for some users. But I don't think it would be an "auto-kill" issue for most people.
So then why would they write their own suite? That's not going to PO Microsoft any less.
My point is: if they're going to be in the office suite business, they shouldn't re-invent any more wheels than absolutely necessary. If they're going to risk the Wrath of Redmond, then take any advantage they can get--fund a port of OO and leverage at least part of the work the OO group has already done.
Other replies to the parent identify the significant issues with OO on the Mac. Having tried for a year to rely on it for word processing, I finally gave up and switched to Mellel--a fine tool for a number of things, but not nearly as muscular as either OO or MS-O. The poor shell integration and reliance on X caused more frustration for me than using it was worth.
That said, OO is a fine product in it's Win and Lin incarnations, and I personally would prefer Apple to fully fund a team dedicated to properly porting the darn thing to Aqua, as opposed to rolling their own from scratch. There is a somewhat beleaguered dev trying to do the job, but they need lots of help. Some developers and cash would make their lives a lot easier.
A funded porting team would also benefit from being able to use the work of the OO core team in dealing with the always-vexing "catch up" issues such as managing the MS format changes, in turn letting the port team focus on making the OO updates play nice in Aqua. Less work for them, quicker updates for the user community.
(Not that Steve gives an expresso shot for what I think, but, hey, I can hope... )
Slashdot Mirror
Indeed. I can see it now:
"Slashdot -- The Fox News Of Technology"
At least there's no rubbish about "fair and balanced" on the banner.
...IMHO, can be found in the following single line from The Fine Article:
But after nearly 15 years in use, the business had grown accustomed to the SBS system, and much of Comair's crew management business processes had grown directly out of it.
(emphasis added)
Talk about putting the cart in front of the horse. This system would never have been replaced before it's crash--the cost of readjusting process and any other attached technology would have dwarfed simply updating the software. There was no business case you could make that would appear to justify the expense. Other than the little matter of "your company won't function if something goes wrong", of course...
Also, you'd never find a decent replacement product--since it's functionality would have to mirror those same system-driven business processes.
The truly major oversight was in letting the package drive how Comair did this part of it's business in the first place. Done otherwise, the meltdown might still have happened, for plenty of reasons outlined in the article. But left this way, this result was pre-ordained. No amount of planning or "risk assessment" was going to counter the inertia created by this process/technology inversion.
IIRC, OS/2 (at least Warp) shipped with a complete install of MS-Win to provide dual-OS support. The OS/2 code contained lots of integration points--if these integration points relied on Win code provided as part of the infamous "divorce decree", that would presumably be off-limits without MS's blessing. If so, would there be enough "untainted" OS/2 code left to be useful as open source?
I didn't use later versions of OS/2, so I don't know if this chimera-like architecture was changed further on...
All the more reason why a chapter in the reviewed book would have been great. There's a definite need for something beyond the javadocs.
Maybe an authoring opportunity here...
Not that any book can cover every useful J2EE tool out there...but leaving XDoclet out, particularly in a book aimed at improving J2EE development time, would be a baffling omission.
I've worked with most of the other tools mentioned in the review and they're all good. But nothing helped speed my own J2EE work more than XDoclet, particularly with EJB's and all their interface definitions, configuration files and container-specific instruction files.
Maybe with some periodicals, but with the WSJ...no thanks. 60+ pages daily, full sheet, financial summaries in agate type--good luck navigating that much content with a PDA, no matter how well it's designed.
Well, it could certainly be used for evil.
It could also be used to protect themselves from a variety of possible legal concerns that might arise from their normal operations.
I work with content and content management systems and see similar clauses in most of our contracts with subject matter experts, authors and provisioning contractors. I'm not a lawyer myself, but have asked our legal staff about why these are included, and the consensus answer I get from them is that they save considerable legal effort dealing with the spiderweb of regulations, laws and statutes encountered when trying to distribute content to users in multiple countries. To paraphrase them, it's essentially a "get out of jail free" card for most common issues of redistribution problems our company might encounter.
Comments from actual lawyers (if any are lurking) would be helpful.
It certainly could be abused, but that's not the first purpose I'd think of.
And maybe we realize that "the idiot is *not* always right". In fact, when the average user knows very little about software in general.
Might be so, but they generally have at least a dim idea of what they want to accomplish with that software. Whatever else your software does well, if it raises too many stumbling blocks between those "idiots" and what they ultimately want to accomplish with it, you'll have a pretty small user group and you'll miss the occasional opportunity to learn how to effectively provide some useful service to those folks, alongside whatever you actually are trying to accomplish yourself.
God forbid, the illiterate idiots might actually have something worth hearing once in awhile...
Claiming tortious interference with an existing business relationship, General Mills has filed suit to block the MS-Chocula deal.
"The Count has been an integral part of our GM team for 34 years. Any money sucking he will be doing will be into General Mills' coffers, not some two-bit meat packing company", apparently referring to the upcoming Longhorn release of Microsoft's flagship product. "We look forward to maintaining the productive relationship between the Count and worldwide youth for many years to come.", according to an unsigned press release from General Mills.
Microsoft spokespeople had no official comment on the suit. Well-connected individuals, speaking anonymously, claimed that a contingency plan, seeking to enlist the services of Count Dracula, has already been put into effect, claiming "Microsoft can make do with pretty much any kind of sucker." One snag in the plan has been the inability of the Count's legal and marketing representatives to make contact with their client, as his last known address has been the subject of considerable debate.
{boy,oh, boy, way too much free time today...}
Already is....
http://www.nvu.com
Why would the Firefox team "hang up the towel?"
Boredom? Demoralized development team tired of duking it out w/ MS?
Seriously, I can't think of any reason why step #5 would occur.
I will say this one more time, since the reply apparently didn't register with you: I am not asking "Slashdotters" for anything, requiring dev. psych comprehension or not. I'm asking the original poster how his/her brother is impaired. What is so fricking hard to comprehend about this?
I would like to help the poster. I don't want to waste their time. The original poster was using quasi-technical language describing an impairment level; I would reasonably presume he/she wouldn't just be pulling that out of their rear. That "correct technical language" is important in identifying what has been observed to be effective with other similar patients. Do you seriously believe this to be pointless?
I think this is enough on this thread already. Hopefully the poster found something useful, or will be willing to provide some more detail for those of us who would like to help him/her. As for you...spend your time suggesting something useful for the poster's sibling, if you're aware of something helpful.
"He can't read or write very well" is a perfectly adequate description.
Perfectly adequate if you want to toss a dart at the neurological dartboard and hope it hits something useful. I suspect the original poster is hoping for something a bit more precise. I would also presume that said poster would probably have a good idea of a diagnosis if his brother's impairment was observed as long ago as his post indicates.
I listed 5 separate potential barriers to learning, several with a pronounced physiological components, several of uncertain origin. These just scratch the surface of observed neuropathology. Each will respond differently to various stimuli including reactive response and short/long term memory transfer, two important components in defining the phenomenon we call "learning". I would hope that the poster would not want his/her time wasted, if a bit of information could help separate useful answers from useless answers.
I would also add that each of the above (with the possible exception of PDD, being fairly new to the DSM) have a quantitative components as part of their diagnostic criteria. Whatever your apparently poor opinion of DSM diagnostic screening may stem from, they're not completely subjective.
Or perhaps you'd prefer to start from scratch with every patient that presents with difficulty recalling and utilizing language and numerical symbology. Your choice, I guess. Be prepared for a very long pre-diagnostic experience. And be a big believer in "lucky guessing".
What is the nature of your brother's disability? PDD? DS? Kanner's autism? Dyslexia? CHI? What defines "effective" software is going to vary considerably based on the diagnosis...
(writing with a very general, not expert, knowledge of how BT works...)
I'm familiar with BT mirroring. I don't dispute that the mirroring would work fine, technically. The problem in this case is business--with mirroring on anything other than a "officially" managed site, in this case, is that this model officially becomes DOA from the advertisers' perspective. If someone in Fandom could conceivably be spawning the actual episode content, how would you know to count them, from a demographic point of view? And without that counting, no ad client is going to pay more than chicken feed to buy slots--from their perspective, those ad buys would be little more than speculation. Throwing an ad out and hoping that someone actually sees it, without having any way of even guestimating viewership. Given the general lack of confidence in the current system (in the US, at least), that wouldn't be an easy sell.
So you either pay through the nose to host, or you surrender most of your potential ad revenue by allowing other people to mirror. Where's the win for the studios?
Now, if you could come up with some way of having the viewer identified to the agency when viewing the episode, that's potentially workable. Maybe there's some magic that would allow this in the BT archtecture. Without it, though, you'd have to go on the assumption that the studio shoulders the whole load.
Like I said originally, it's an interesting idea. I'd love it myself and would probably use it. Just come up with a way to keep the ad buyers comfortable that their money is actually accomplishing something.
OK, I'll bite...
Flash back to 1982 (and, yes, I'm old enough to actually remember 1982): you could take the above post verbatim, replace every instance of "China" with "Japan" and quite a few people would probably agree with it.
Didn't quite work out that way though...
How would they incur "substantial" costs for storage and transmission bandwidth using bittorrent? Currently these shows are being seeded by people with cable modems to THOUSANDS of people at the same time.
The original poster's plan would require One True Torrent site, run by the studio, to source the episodes. The studio wouldn't be able to rely on Fandom to mirror content and thereby spread the storage/bandwidth costs around.
Further, said "official" site would be responsible for serving massive content streams to hundreds of thousands, if not millions of individuals weekly.
Big-time money needed. Every ISP on the planet would be licking it's chops at the thought of putting a meter on this.
Interesting idea. You'd have a "official" BT site for series episodes (necessary so that ad buyers could verify actual download counts).
Potential snag: you'd be adding potentially substantial costs for storage and transmission bandwidth to the existing cost of production.
How do you subsidize these costs assuming...
1. You probably won't be able to up slot costs significantly. Even allowing for the attraction of more solid view counts, why would an agency spend more money buying slots here when the same content would reach more people for less money over the air?
2. Networks will not accept any degradation of profit margins for the show.
Thoughts?
Actually the address itself:
http://switch.atdmt.com/action/
yields the same 1 px. image. As does adding any text at all thereafter.
So for all this demonstrates, some web monkey for Avenue A just got fat-fingered and typed a '5' when he meant a '4'.
Move along folks. The G5 PB's will be here when they're here...
so all the people who do observe it are dragging you down with them.
Never, I say! It's bad enough that the whole Cristianity thing was founded by a nice Jewish boy gone renegade. Now I have to get dragged down by their stinking holiday as well? Ptah.
And, while we're on the topic of holidays, if Dr. Arnalls thinks that Christmas is the best he can do for emotional nadirs, then he doesn't know bubkes about bad. You want bad? Try any one of my faith's holidays. Every single one of them is predicated on remembering some group's attempt to completely eradicate us. Even bleeping Hannukah. Festival of Joy, indeed.
And don't get me started on what a merry day Yom Kippur is...
T: Time since Christmas
Well, as an observant Jew, I suppose I'll need to re-calculate this using a religious-orientation-appropriate substitute.
Any others of the tribe lurking? If so, any suggestions? Maybe Tisha b'Av?
Those of other religious persuasions, feel free to chime in with your own sectarian-oriented suggestions as well.
And, I guess this gets the atheists completely off the hook...enjoy your Monday, you Godless unbelievers!
None of the three you mention are still with their respective companies (hence the term 'fallen').
'Deposition Daryl' gets a pass for this year. At the rate things are going, however, he'll be a shoo-in for next year's list.
Thanks for the reply. I disagree with the need to dump the OO codebase. UI issues notwithstanding (since Apple would be re-writing much of the UI as a port anyway), the majority of the document manipulation, storage and formatting functions in OO are independent of the UI. It's this work that I would prefer Apple leverage rather than re-invent.
Don't get me wrong: the UI would be a huge task. But I don't think Apple is going to save any time by having both UI and document engine tasks on their to-do lists.
Regarding speed and memory size--obviously those items are in the "YMMV" group. Speed is and was a potential issue--we'll see how it works with 2.0 final. Memory...I don't know. It does use a lot. That might make a difference for some users. But I don't think it would be an "auto-kill" issue for most people.
So then why would they write their own suite? That's not going to PO Microsoft any less.
My point is: if they're going to be in the office suite business, they shouldn't re-invent any more wheels than absolutely necessary. If they're going to risk the Wrath of Redmond, then take any advantage they can get--fund a port of OO and leverage at least part of the work the OO group has already done.
Other replies to the parent identify the significant issues with OO on the Mac. Having tried for a year to rely on it for word processing, I finally gave up and switched to Mellel--a fine tool for a number of things, but not nearly as muscular as either OO or MS-O. The poor shell integration and reliance on X caused more frustration for me than using it was worth.
That said, OO is a fine product in it's Win and Lin incarnations, and I personally would prefer Apple to fully fund a team dedicated to properly porting the darn thing to Aqua, as opposed to rolling their own from scratch. There is a somewhat beleaguered dev trying to do the job, but they need lots of help. Some developers and cash would make their lives a lot easier.
A funded porting team would also benefit from being able to use the work of the OO core team in dealing with the always-vexing "catch up" issues such as managing the MS format changes, in turn letting the port team focus on making the OO updates play nice in Aqua. Less work for them, quicker updates for the user community.
(Not that Steve gives an expresso shot for what I think, but, hey, I can hope... )