The Comair failure left people stranded around the holidays a few years back, because their system couldn't handle all the crew changes after a big snowstorm.
LaTeX is more like a programming language than a word processor and as such will not scale well to a bigger team with diverse skills. Inevitably the production process will single-thread through the one or two people who really know the tool.
A better solution is delegating to applications' own "diff" features to display differences between versions graphically.
I see a much less pernicious motivation for wanting to have tiered internet service. First, you need the motivation to build faster backbones in the first place. If you can't charge more for faster service, why bother improving it? Think about how well rent control worked out.
Second, I can see the telecoms' frustration with not sharing as much in the success of Internet companies like Google, after building (or over-building in some cases) the infrastructure to make it possible. My guess is they are just looking for ways to get a bigger piece of the pie, more than they are looking to control content or block competitors. And, we *do* already have anti-trust laws that would likely cover the most egregious cases.
Some important criteria for a good design document: - it should be the right amount of documentation for the job, not overkill - it should accurately reflect the real implemented system - it should supplement, not be a replacement for, real, working code - when feasible, real working prototypes are better than documents
There's a world of difference between writing software for nuclear reactors and writing a typical "web page to display results of db queries". It's folly to apply the same standards to both.
In the latter case, when you're dealing with "pure" information systems (i.e., a bug in the system won't cause a reactor meltdown or a plane crash) requirements are often nebulous. Clients often don't fully understand their requirements until they see the finished product. So you're best off producing a working prototype or demo rather than a document.
if you have a requirement that you produce a polished "design document" before moving on to writing code, you're going to waste a lot of cycles on something that's going to become irrelevant and useless anyway. You can easily spend weeks perfecting a document that will just be thrown out once too many things change as a result of bug fixes, new features, etc.
that said, if your software is controlling heart monitors, airplanes, or the Mars Rover, you need to have a much more rigorous design and requirements process up front. My point is that you have to pick the right process for the job, though, and avoid one-size-fits-all "thou shalt write a long design document" dictates.
IANAL, but by themselves, records from these cards should not even be considered probable cause, given the the complete lack of any kind of authentication. At the Safeway by my house in Maryland, you can just punch in your phone number, no questions asked.
This is not necessarily a problem with the cards themselves--it is a problem with the misuse of the raw data at the wrong level of granularity. The point of supermarket loyalty cards is to find trends that can be used for marketing purposes. As such, the standard of accuracy for any *individual transaction* is not necessarily that stringent, because what counts is the *aggregate* after individual errors cancel out. The probability for error with any individual transaction is too high to throw someone in jail over that alone, even temporarily.
Perhaps there's a case for wrongful arrest here, given the way that the charges seemed to rely entirely on the abuse and misinterpretation of data. More likely, though, the man should consider suing Safeway for damages stemming from mis-representing the data to the police in a way that construed more accuracy to individual transactions than it deserves.
OpenOffice, on the other hand, while getting very good, is still not as good as Microsoft Office in many ways.
The main weakness of OpenOffice, IMO, is its ability to read and write M$ Office files without munging them. I just bought a slick new IBM Thinkpad and resented that over 10% of pricetag was for the Office licence, because I had to have PowerPoint... not because OpenOffice Impress isn't good enough for my needs, but because I have to interact with other people who use PowerPoint. And I'm getting too old to be an l33t war3z d00d.:-)
So, the DMCA is like an end-run around previous court decisions asserting fair use. AFAIK, the DMCA doesn't explicitly deny fair use rights (backups, format change, etc.); it says you can't "circumvent" those technologies that prevent copying in general, fair use or otherwise.
in theory, enforcement of the DMCA should be unconstitutional in cases where circumvention is merely incidental to fair use. So far, though, I don't think there have been any attempts to prosecute *individuals* in cases where fair use was blatantly obvious (for example, ripping your own DVDs to a laptop for viewing on an airplane; and no, sharing MP3s with thousands of your "closest friends" on Kazaa is not fair use). That would clearly be going too far, to the point where even Joe Sixpack would think there's something seriously fucked up with the DMCA.
The main problem with public support for the DMCA and DRM is that the consequences haven't really hit home yet for your average joe. Once people realize that all their new CDs are "broken" you might see some corrective action. Or more likely, the law just won't be enforced against individuals.
Another theory on the declining sales: baby boomers artificially inflated CD sales by repurchasing music they already owned on LP/cassette/8-track in bulk. At some point, they had their fill and sales levelled off accordingly.
Also, what about the Wal-Mart effect? Wal-Mart drives a hard bargain and exerts downward price pressure on just about everything, and they're a significant retailer of CDs and DVDs. That's going to cut into profit margins.
offshoring vs. obsoleting
on
Offshoring IT
·
· Score: 1
Why is losing a job to outsourcing worse than having it be obsoleted outright because of improvements in labor-saving technology?
Here's an example: "computer" used to be a job title held by people who tabulated numbers manually before digital calculators. Clearly no one makes a living at that anymore. But let's say those jobs had gone to India instead of being replaced by technology. Would it have made a difference?
I think the issue is, people take it personally if they perceive a one-for-one job transfer from an American to a foreigner. Losing your six-figure job doing legacy COBOL apps to an Indian triggers thoughts like "that job *should have* stayed here" because said job still exists, somewhere else. But dumping the old system and the jobs with it isn't a story, it's just business as usual.
Bottom line: this industry is all about accelerating change, and if you want to survive you have to "embrace change" and keep up, or go the way of the dodo. Outsourcing itself is a red herring. If you're that high-paid mainframe guy still maintaining apps from the '70s, your job is vulnerable. Doesn't matter whether you lose your job to someone in India or whether it goes away outright--for some jobs, Bangalore may just be a pit stop on the road to obsolecence.
Slashdot Mirror
The Comair failure left people stranded around the holidays a few years back, because their system couldn't handle all the crew changes after a big snowstorm.
2 212&from=rss
http://it.slashdot.org/article.pl?sid=04/12/26/05
This was a significant operational failure, as opposed to a project management failure.
LaTeX is more like a programming language than a word processor and as such will not scale well to a bigger team with diverse skills. Inevitably the production process will single-thread through the one or two people who really know the tool.
A better solution is delegating to applications' own "diff" features to display differences between versions graphically.
I see a much less pernicious motivation for wanting to have tiered internet service. First, you need the motivation to build faster backbones in the first place. If you can't charge more for faster service, why bother improving it? Think about how well rent control worked out.
Second, I can see the telecoms' frustration with not sharing as much in the success of Internet companies like Google, after building (or over-building in some cases) the infrastructure to make it possible.
My guess is they are just looking for ways to get a bigger piece of the pie, more than they are looking to control content or block competitors. And, we *do* already have anti-trust laws that would likely cover the most egregious cases.
Some important criteria for a good design document:
- it should be the right amount of documentation for the job, not overkill
- it should accurately reflect the real implemented system
- it should supplement, not be a replacement for, real, working code
- when feasible, real working prototypes are better than documents
There's a world of difference between writing software for nuclear reactors and writing a typical "web page to display results of db queries". It's folly to apply the same standards to both.
In the latter case, when you're dealing with "pure" information systems (i.e., a bug in the system won't cause a reactor meltdown or a plane crash) requirements are often nebulous. Clients often don't fully understand their requirements until they see the finished product. So you're best off producing a working prototype or demo rather than a document.
if you have a requirement that you produce a polished "design document" before moving on to writing code, you're going to waste a lot of cycles on something that's going to become irrelevant and useless anyway. You can easily spend weeks perfecting a document that will just be thrown out once too many things change as a result of bug fixes, new features, etc.
that said, if your software is controlling heart monitors, airplanes, or the Mars Rover, you need to have a much more rigorous design and requirements process up front. My point is that you have to pick the right process for the job, though, and avoid one-size-fits-all "thou shalt write a long design document" dictates.
Actually, it's the "Blue Screen of Death states" against the "RedHat states."
IANAL, but by themselves, records from these cards should not even be considered probable cause, given the the complete lack of any kind of authentication. At the Safeway by my house in Maryland, you can just punch in your phone number, no questions asked.
This is not necessarily a problem with the cards themselves--it is a problem with the misuse of the raw data at the wrong level of granularity. The point of supermarket loyalty cards is to find trends that can be used for marketing purposes. As such, the standard of accuracy for any *individual transaction* is not necessarily that stringent, because what counts is the *aggregate* after individual errors cancel out. The probability for error with any individual transaction is too high to throw someone in jail over that alone, even temporarily.
Perhaps there's a case for wrongful arrest here, given the way that the charges seemed to rely entirely on the abuse and misinterpretation of data. More likely, though, the man should consider suing Safeway for damages stemming from mis-representing the data to the police in a way that construed more accuracy to individual transactions than it deserves.
The main weakness of OpenOffice, IMO, is its ability to read and write M$ Office files without munging them. I just bought a slick new IBM Thinkpad and resented that over 10% of pricetag was for the Office licence, because I had to have PowerPoint... not because OpenOffice Impress isn't good enough for my needs, but because I have to interact with other people who use PowerPoint. And I'm getting too old to be an l33t war3z d00d. :-)
So, the DMCA is like an end-run around previous court decisions asserting fair use. AFAIK, the DMCA doesn't explicitly deny fair use rights (backups, format change, etc.); it says you can't "circumvent" those technologies that prevent copying in general, fair use or otherwise.
in theory, enforcement of the DMCA should be unconstitutional in cases where circumvention is merely incidental to fair use. So far, though, I don't think there have been any attempts to prosecute *individuals* in cases where fair use was blatantly obvious (for example, ripping your own DVDs to a laptop for viewing on an airplane; and no, sharing MP3s with thousands of your "closest friends" on Kazaa is not fair use). That would clearly be going too far, to the point where even Joe Sixpack would think there's something seriously fucked up with the DMCA.
The main problem with public support for the DMCA and DRM is that the consequences haven't really hit home yet for your average joe. Once people realize that all their new CDs are "broken" you might see some corrective action. Or more likely, the law just won't be enforced against individuals.
Another theory on the declining sales: baby boomers artificially inflated CD sales by repurchasing music they already owned on LP/cassette/8-track in bulk. At some point, they had their fill and sales levelled off accordingly.
Also, what about the Wal-Mart effect? Wal-Mart drives a hard bargain and exerts downward price pressure on just about everything, and they're a significant retailer of CDs and DVDs. That's going to cut into profit margins.
Why is losing a job to outsourcing worse than having it be obsoleted outright because of improvements in labor-saving technology?
Here's an example: "computer" used to be a job title held by people who tabulated numbers manually before digital calculators. Clearly no one makes a living at that anymore. But let's say those jobs had gone to India instead of being replaced by technology. Would it have made a difference?
I think the issue is, people take it personally if they perceive a one-for-one job transfer from an American to a foreigner. Losing your six-figure job doing legacy COBOL apps to an Indian triggers thoughts like "that job *should have* stayed here" because said job still exists, somewhere else. But dumping the old system and the jobs with it isn't a story, it's just business as usual.
Bottom line: this industry is all about accelerating change, and if you want to survive you have to "embrace change" and keep up, or go the way of the dodo. Outsourcing itself is a red herring. If you're that high-paid mainframe guy still maintaining apps from the '70s, your job is vulnerable. Doesn't matter whether you lose your job to someone in India or whether it goes away outright--for some jobs, Bangalore may just be a pit stop on the road to obsolecence.