I had a very similar experience. After years of faithfully backing up to.Mac, I actually needed to recover my data and Backup ran for hours without accomplishing anything. No error message, but no recovered files either. After three attempts of 8 or more hours each, I finally went to the Genius Bar for help.
The Apple Genius ("That's only my job title, and not an actual description.") blamed the problem on my numerous incrementals. He said that Backup needs full backups every so often to work reliably. He suggested weekly. Gee, it would have been nice to roll that into the program.
HERE'S THE GOOD PART:
The files created by Backup are actually bundles, which means you can 'cd' into them from the command line. The directory structure within the bundles mirrors the directory being backed up, though it is a sparse tree. A given incremental backup only contains the files that were changed. It didn't take much work to whip up a Python program to copy files out of each bundle, starting with the earliest. If I could perform the recovery with well under an hour of coding and no prior experience, why couldn't Apple do it with years of development time?
Of course, my less-frequent full backup made with rsync worked flawlessly.
So how good is the coverage of various TiVo models? I have a Hughes HDVR2 and while I love the dual-tuners and high image quality, much of the hacking info I have found does not apply to my unit.
Some software now contacts the publisher to make sure the license key is valid. We can expect this practice to grow as time goes on. As more and more software enforces licensing by phoning home, we have a new risk.
Suppose some big software publisher, Microsoft or otherwise, were to drop off the net. What happens when their software cannot contact the license servers? Answer: at some point, legitimate users cannot use the software.
So, any entity that depends heavily on a single publisher has a huge risk to contend with. If someone were to sabotage Microsoft by attacking their license servers, then the US Government would encounter a serious disruption. This risk applies just as well to NGO's and private companies. How many of us could do our job if our computers suddenly ceased to function?
As Bruce Schneier says, the cutting edge is always moving, but the low-end is here to stay.
Old standards have a way of hanging on, even when there are superior replacements. Look at all the strange, vestigial crap in PC hardware. Look at NTSC video, 8.3 filenames. You'd be amazed how many large companies keep important data in VSAM files instead of real databases. People might start using new standards for new applications, but the old standards will still cling in the old applications or eveb in new applications that must interact with old ones.
Are there exceptions where old technology was phased quickly? Sure. The cost of change can be high, and business people generally want technology that is Good Enough rather than following the latest and greates trends just for their own sake.
You should see the old tech that is still used in the finantial sector. In these parts, the rule of thumb is "If it ain't broke, don't fix it." When you are dealing with people's money (and government regulations therof), the cost of botching a change is very high.
The meta-title for this thread could just as well be "What makes a powerful flamewar?"
As others have mentioned, the expressive power of a language has to be weighed against the availability of tools, developers, etc. However, there is another dimension to this: What sort of developer is proficient in a particular language?
Lisp is a powerful and flexible programming language. Lisp programmers can often accomplish quite a bit in a short time. Is this purely due to Lisp, or to the programmers? If the programmers who end up learning Lisp tend to be a cut above the norm, then the productivity we see from Lisp programmers will tend to be a cut above as well.
I don't agree with this. It is the coder's responsibility to come up with the schedule. You may not know precisely how long it will take to find the bug, but saying the project will be done "whenever" is not acceptable. If the coders made the schedule but aren't sticking to it, they need to explain why it's taking longer than expected and give a new estimate of how long it will take.
I agree with you, but we are talking about two different things.
The issue is one of scale. On a macro scale, it is possible to estimate when a project will be done. (The quality of such estimates in our industry is a matter I will leave to others.) As time goes by, development teams can keep deadlines intact by managing scope. Some features are delayed until the next release. Not every bug gets fixed.
On a micro scale, problems can vary. Some are continuous and some are discreet. Continuous problems lend themselves to measurement. "Well, our design for this module has ten classes, and I have implemented five of them so I am about half done." (That's a gross over-simplification of the coding process, but you get the idea.) If I can measure my progress at a task, then I can estimate the time to completion, and refine that estimate as time goes on.
Discreet problems are either done or undone. They do not lend themselves to measurement. One does not iterate towards a solution-- one simply searches until the solution is found. A non-technical example is finding your car keys. It's not meaningful to say "I am 50% done with my search" or "it will take me two more minutes." The fact is, the search will take as long as it takes.
3) Focus on the work itself, not the window dressing. The hours, manner, and location in which I work don't matter so long as I deliver good results on time.
4) Recognize that some technical problems are not progressive and people cannot give a time estimate. "When will you find the bug?" often does not have a meaningful answer. There is no such thing as X percent done with this kind of task and the rate of progress cannot be measured. It's done when it's done.
5) Don't be afraid to discipline those who need it.
6) Dish out praise when it is warranted. Our egos sometimes need stroking.
7) Beware of false economies. When schedules are tight, do not throw good software engineering practices out the window. If you do so, it will usually bite you in the ass.
8) Pay attention to team building. Will a prospective new hire fit in well? How can you help people to work well together? This will sometimes mean finding a way to keep incompatible workers out of the others' hair. Play together outside of work.
9) Pay attention to skill building. When possible, assign people to tasks (or suggest methods) where they can grow. Some tasks will take a bit longer in the short term, but you win in the long term. Skilled people can do more and work faster. People who feel like they are growing are happier, more productive, and stay around longer.
10) Set priorities and stick to them.
11) Don't bullshit.
12) Set a good example.
13) Accept the fact that people have lives outside of work.
14) Realize that time is a finite resource. If I leave my primary task to fight a fire, that means I am not progressing on my primary task.
...it would allow many people who don't wish to be subjected to violence/nudity/language a chance to watch any movie they want without waiting months for it to be released on network television, already PG-13ized.
This is great. Now I can credibly rent R and PG-13 movies while insisting to my friends and neighbors that I am only seeing G-rated content. Who is to know what settings I really use for playback? I maintain the outward appearance of the moral high ground while still getting all the good stuff I need to be a man.
That is a bad question to bring to Slashdot. Hopefully you have a friend who is a lawyer. Go ask him or her. Perhaps you could even hire a lawyer to discuss your situation for a bit. If you bring a like-minded coworker, the two of you could split the cost. Let us know what you find. I'm sure many readers are interested in the answer.
Slashdot is not a community of lawyers, and the legal advice you get here is worth what you pay for it.
While I delight in the online communities that I visit-- including the mighty Slashdot --I am amazed at some of the questions people bring to online forums.
Why do people ask random schmoes on the net for legal, medical, or other specialized advice instead of asking lawyers, health care workers, or other specialists? Why do they (not on Slashdot so much) ask questions that can be answered with a search engine in about five seconds?
Slashdot kicks ass, but it isn't everything. Slashdot is a great place to find out about all manner of issues relevant to us as nerds. Would you post a question to Slashdot about how to fix your motorcycle? Or how to get your cat to adapt to its new litter box? Of course not. So why are you asking for legal advice?
As Joebob Briggs says, I'm surprised I have to explain this.
though if your goal is to make sure the artists get their $.002 from the record label for each album sold, it's not so hot.
Assuming the CD is not a bootleg, and the original purchaser did not steal it from the record label, then the artist already got his two cents from the label at the time of original purchase. If artists (and labels!) were paid for secondary sales, they would be getting four cents instead of two.
Since the law doesn't gude us, employers will do whatever the job market will tolerate. If the job market is slow (and it has dropped of a lot here in the SF Bay Area), then it is a lot harder for employees or contractors to stipulate terms. Do your best, but don't blow a whole deal over it.
When hiring contractors, a contracting agency asked me to pay a premium of 3 (or was it 4) hours per week, with the understanding that if I had to page anybody, the first 3 (or 4) hours were already paid for. This is in 1996 or so-- things were not slow like today, but it was before the market went totally nuts.
For myself, if I am to be on-call, then I insist on having enough control over the system in question that I can prevent an after-hours problem in the first place. If I can't take reasonable steps to keep things working, then I don't want to take the heat when they break. Of course, that position won't work for everybody, especially in this market.
Unions might provide some help with this question, but fundamentally their value models don't work well in IT.
I would have said Pole Position, but after reading the article, I wonder whether those Atari was licensing as opposed to real adverts...
Does anybody know of a video game before Pole Position that contained what looked like advertising? What about the first real (ie, $$ paid to the publisher) ad in a video game?
If anybody from the Mozilla project is reading this, please just concentrate on shipping a browser that is fast and reliable. Let the fancy stuff come after you have mastered the basics.
As Joe Bob Briggs says, I'm surprised I have to explain this.
It seems unlikely that you will convince the HR
people to keep flex time.
If flex time is important to you, then quit if
they take it away. The job market is booming
right now, especially for techies. It is a lot
easier to take your talent elsewhere than it
is to fight a corporate culture that doesn't
suit you.
Answer number one: If you are working on a commercial-quality application (even if it is open source or in-house), then I STRONGLY urge you to use an existing protocol that uses encryption (like SSL or SSH) and that you use an existing implementation rather than roll your own. There are multiple implementations of both protocols floating around, so just pick one. Even with the best crypto in the world, there are still plenty of ways to screw up the protocol or implementation. If you are just doing this for fun or as a learning experience, then we move to answers two and three...
Answer number two: As other posters have indicated, known public key algorithms are too slow to be of much use in encrypting large amounts of data. If you look at existing implementations, nobody does bulk encryption with a public key algorithm. Generate a random session key, send it to the other end encrypted with your public key algorithm, then use a stream cipher of your choice to do the bulk of the work.
This means, as hinted at above, that you don't just need an algorithm you need a protocol. Your protocol must address questions about how you generate your keys, how once side informs the other, who gets to generate them, how often (or if) they change, etc. It is possible to keep your protocol quite simple, but you need to at least think about such things.
Answer number three: In a word "modes". There are various ways to apply block encryption algorithms such that you can use them as stream algorithms. Because the public key algorithms are slow, this application will be slow, but it does work and is generally considered an OK cryptographic practice to apply the various modes where appropriate. So, what are the modes? What are their pros and cons? See chapter 9 of Bruce Schneier's Applied Cryptography.
If you are interested in this stuff, then you should really get a copy of Schneier's book and check it out. It's chok full O' cryptographic goodness. If your local bookstore doesn't have it, then fatbrain.com or your favorite online bookseller will.
One final thought. Messing around with crypto is a lot of fun, but it is harder than it might seem. There are a lot of implementation pitfalls that can render your crypto worthless or nearly so. When you are doing something really important, stick to existing algorithms and implementations.
Every time my PacBell DSL goes out (weekly or daily occurrence depending on my karma), my Ricochet keeps my CVS reporitories connected...
I've been contemplating the same thing for a while, as my DSL reliability has been in the toilet. Can the rest of the net still find you when the DSL is out? If so, are you doing anything fancy with the routing or just relying on DNS to do the trick?
At the same time, it must be noted than any encrypted message is breakable by brute force, given enough resources.
You make an excellent point about key lifetimes, but the statement above is not correct.
If you want to know why, read Chapter 7 of Bruce Schneier's Applied Cryptography. The chapter is fairly short, and you could even read it in the bookstore if you don't want to buy the book. (Though I do recommend the rest of the book as well.)
The short version of the chapter is that beyond a certain key size, there simply is not enough time, matter and energy available to complete a brute-force attack before the sun swallows up the earth. Once the key is big enough, a break depends on finding a weakness in the algorithm itself or compromising the key in some other way. Other ways could include: physical theft, cameras, bribery, keystroke monitors etc.
A trusted third party won't help. You still need the cooperation of the software on the receiver's computer. The receiver could modify the software such that it does not cooperate.
Thus it requires a certain amount of trust in the receiving party that nothing has been tampered with. If you trust the recipient so much, why not just ask him/her to delete the message? If you trust the person so little, why are you sending the message in the first place?
I'll leave the NT/Unix flamewar to somebody else. I am tired of that one.
That issue aside, I can say that large companies are often not very price-sensitive w.r.t. big projects. A big development project will often end up saving millions of dollars, or producing millions of dollars in revenue. The people who sign the checks don't care about a difference of a few grand. They simply want to go with what they know will work.
In fact, corporate culture often runs in the opposite direction of price sensitivity. Many IT managers assume that you get what you pay for. If a product is cheap, it must not be very good. If it is free, it must be a piece of crap. Perl, Apache, and Linux are changing this perception, but only very slowly.
Inertia plays a big part as well. Nobody wants to change databases when an application works fine, so existing installations will tend to stay faithful to one vendor. We tend to think of Oracle as the incumbent, but there is a huge amount of stuff out there still in DB2. Byte magazine claims that 80% of the world's data is in DB2 databases.
Not that NT and Linux won't make inroads, but the target market for the high-margin vendors will be one of the last to fall. Cost and performance matter, but so does reputation.
Visio may be used extensively worldwide, but seeing it described with words like "incredible" makes me suspect that most Slashdot folk have not used a lot of other graphics software. Yes, Visio has a lot of features, but it is one of the klunkiest graphics programs I have ever seen.
For all the many faults of the Macintosh, it pretty much rules the graphic design space. If any Slashdot reader needs to do some serious graphics work, then spend some serious time using one of the many excellent graphics applications for the Mac. I say 'serious time' because just dabbling won't allow you to get past the mere fact that you are using a different OS. By putting in some real time, you should be able to get past the unfamiliarity factor and see some of the advantages.
I'm sure that Visio has some useful features that are really hard to find elsewhere, and anybody who is comfortable with it may as well keep using it. At the same time, if we spread the word far and wide that a klunky product is actually really good, then we make it that much less likely that Microsoft will ever improve the UI.
the author of this article doesn't realize why home consumers buy macs: simplicity. does he want to answer the tech support call when mrs. smith from Greendale, Ohio has to edit her inetd.conf?
he also fails to recognize that people who use linux find it, not the other way around. there is a pre-requisite to using linux, and that's knowing how to use linux. all the marketing in the world won't teach this to the customer what to do at a login prompt.
there's also a mention here of the performance of linux far outpacing that of macos. sure, it does when you're benchmarking, but you're not comparing similar environments. the macos uses more overhead to provide user services in the GUI. if you loaded up a window manager which replicates EVERY feature of the macos GUI, i'm sure linux would slow down considerably. you're comparing apples to oranges (pardon the pun.;)
I do agree that Apple will have a surgence in popularity. With all the technological advancement we've been priveleged to witness, why should computers be problematic? Apple has always been focused on the user. while everyone else is talking about pre-emptive multitasking and protected memory, they've been neglecting the user in favor of the computer. windows is slowly getting easier, but the frustration-factor is still high for some of the most simple tasks. linux is getting easier slowly, but troubleshooting is still far beyond the average user.
apple started out with ease of use, and now with macos X they'll be adding the low-level features. they'll have the horses and the cart. i don't think it will be quite as easy as apple hopes; but a unified api set (carbon) shows promise. they'll sure beat windows2001 out the door.
Slashdot Mirror
I had a very similar experience. After years of faithfully backing up to .Mac, I actually needed to recover my data and Backup ran for hours without accomplishing anything. No error message, but no recovered files either. After three attempts of 8 or more hours each, I finally went to the Genius Bar for help.
The Apple Genius ("That's only my job title, and not an actual description.") blamed the problem on my numerous incrementals. He said that Backup needs full backups every so often to work reliably. He suggested weekly. Gee, it would have been nice to roll that into the program.
HERE'S THE GOOD PART:
The files created by Backup are actually bundles, which means you can 'cd' into them from the command line. The directory structure within the bundles mirrors the directory being backed up, though it is a sparse tree. A given incremental backup only contains the files that were changed. It didn't take much work to whip up a Python program to copy files out of each bundle, starting with the earliest. If I could perform the recovery with well under an hour of coding and no prior experience, why couldn't Apple do it with years of development time?
Of course, my less-frequent full backup made with rsync worked flawlessly.
So how good is the coverage of various TiVo models? I have a Hughes HDVR2 and while I love the dual-tuners and high image quality, much of the hacking info I have found does not apply to my unit.
Some software now contacts the publisher to make sure the license key is valid. We can expect this practice to grow as time goes on. As more and more software enforces licensing by phoning home, we have a new risk.
Suppose some big software publisher, Microsoft or otherwise, were to drop off the net. What happens when their software cannot contact the license servers? Answer: at some point, legitimate users cannot use the software.
So, any entity that depends heavily on a single publisher has a huge risk to contend with. If someone were to sabotage Microsoft by attacking their license servers, then the US Government would encounter a serious disruption. This risk applies just as well to NGO's and private companies. How many of us could do our job if our computers suddenly ceased to function?
--mkb
As Bruce Schneier says, the cutting edge is always moving, but the low-end is here to stay.
Old standards have a way of hanging on, even when there are superior replacements. Look at all the strange, vestigial crap in PC hardware. Look at NTSC video, 8.3 filenames. You'd be amazed how many large companies keep important data in VSAM files instead of real databases. People might start using new standards for new applications, but the old standards will still cling in the old applications or eveb in new applications that must interact with old ones.
Are there exceptions where old technology was phased quickly? Sure. The cost of change can be high, and business people generally want technology that is Good Enough rather than following the latest and greates trends just for their own sake.
You should see the old tech that is still used in the finantial sector. In these parts, the rule of thumb is "If it ain't broke, don't fix it." When you are dealing with people's money (and government regulations therof), the cost of botching a change is very high.
--mkb
The meta-title for this thread could just as well be "What makes a powerful flamewar?"
As others have mentioned, the expressive power of a language has to be weighed against the availability of tools, developers, etc. However, there is another dimension to this: What sort of developer is proficient in a particular language?
Lisp is a powerful and flexible programming language. Lisp programmers can often accomplish quite a bit in a short time. Is this purely due to Lisp, or to the programmers? If the programmers who end up learning Lisp tend to be a cut above the norm, then the productivity we see from Lisp programmers will tend to be a cut above as well.
I agree with you, but we are talking about two different things.
The issue is one of scale. On a macro scale, it is possible to estimate when a project will be done. (The quality of such estimates in our industry is a matter I will leave to others.) As time goes by, development teams can keep deadlines intact by managing scope. Some features are delayed until the next release. Not every bug gets fixed.
On a micro scale, problems can vary. Some are continuous and some are discreet. Continuous problems lend themselves to measurement. "Well, our design for this module has ten classes, and I have implemented five of them so I am about half done." (That's a gross over-simplification of the coding process, but you get the idea.) If I can measure my progress at a task, then I can estimate the time to completion, and refine that estimate as time goes on.
Discreet problems are either done or undone. They do not lend themselves to measurement. One does not iterate towards a solution-- one simply searches until the solution is found. A non-technical example is finding your car keys. It's not meaningful to say "I am 50% done with my search" or "it will take me two more minutes." The fact is, the search will take as long as it takes.
--mkb
1) Communicate your expectations clearly.
2) Listen.
3) Focus on the work itself, not the window dressing. The hours, manner, and location in which I work don't matter so long as I deliver good results on time.
4) Recognize that some technical problems are not progressive and people cannot give a time estimate. "When will you find the bug?" often does not have a meaningful answer. There is no such thing as X percent done with this kind of task and the rate of progress cannot be measured. It's done when it's done.
5) Don't be afraid to discipline those who need it.
6) Dish out praise when it is warranted. Our egos sometimes need stroking.
7) Beware of false economies. When schedules are tight, do not throw good software engineering practices out the window. If you do so, it will usually bite you in the ass.
8) Pay attention to team building. Will a prospective new hire fit in well? How can you help people to work well together? This will sometimes mean finding a way to keep incompatible workers out of the others' hair. Play together outside of work.
9) Pay attention to skill building. When possible, assign people to tasks (or suggest methods) where they can grow. Some tasks will take a bit longer in the short term, but you win in the long term. Skilled people can do more and work faster. People who feel like they are growing are happier, more productive, and stay around longer.
10) Set priorities and stick to them.
11) Don't bullshit.
12) Set a good example.
13) Accept the fact that people have lives outside of work.
14) Realize that time is a finite resource. If I leave my primary task to fight a fire, that means I am not progressing on my primary task.
15) Negotiate realistic deadlines.
16) Know your stuff.
17) Give people good tools.
18) Keep your word.
This is great. Now I can credibly rent R and PG-13 movies while insisting to my friends and neighbors that I am only seeing G-rated content. Who is to know what settings I really use for playback? I maintain the outward appearance of the moral high ground while still getting all the good stuff I need to be a man.
Once again, technology saves the day!
That is a bad question to bring to Slashdot. Hopefully you have a friend who is a lawyer. Go ask him or her. Perhaps you could even hire a lawyer to discuss your situation for a bit. If you bring a like-minded coworker, the two of you could split the cost. Let us know what you find. I'm sure many readers are interested in the answer.
Slashdot is not a community of lawyers, and the legal advice you get here is worth what you pay for it.
While I delight in the online communities that I visit-- including the mighty Slashdot --I am amazed at some of the questions people bring to online forums.
Why do people ask random schmoes on the net for legal, medical, or other specialized advice instead of asking lawyers, health care workers, or other specialists? Why do they (not on Slashdot so much) ask questions that can be answered with a search engine in about five seconds?
Slashdot kicks ass, but it isn't everything. Slashdot is a great place to find out about all manner of issues relevant to us as nerds. Would you post a question to Slashdot about how to fix your motorcycle? Or how to get your cat to adapt to its new litter box? Of course not. So why are you asking for legal advice?
As Joebob Briggs says, I'm surprised I have to explain this.
Since the law doesn't gude us, employers will do whatever the job market will tolerate. If the job market is slow (and it has dropped of a lot here in the SF Bay Area), then it is a lot harder for employees or contractors to stipulate terms. Do your best, but don't blow a whole deal over it.
When hiring contractors, a contracting agency asked me to pay a premium of 3 (or was it 4) hours per week, with the understanding that if I had to page anybody, the first 3 (or 4) hours were already paid for. This is in 1996 or so-- things were not slow like today, but it was before the market went totally nuts.
For myself, if I am to be on-call, then I insist on having enough control over the system in question that I can prevent an after-hours problem in the first place. If I can't take reasonable steps to keep things working, then I don't want to take the heat when they break. Of course, that position won't work for everybody, especially in this market.
Unions might provide some help with this question, but fundamentally their value models don't work well in IT.
Hope that helps.
--mkb
I would have said Pole Position, but after reading the article, I wonder whether those Atari was licensing as opposed to real adverts...
Does anybody know of a video game before Pole Position that contained what looked like advertising? What about the first real (ie, $$ paid to the publisher) ad in a video game?
--mkb
As Joe Bob Briggs says, I'm surprised I have to explain this.
--mkb
If flex time is important to you, then quit if they take it away. The job market is booming right now, especially for techies. It is a lot easier to take your talent elsewhere than it is to fight a corporate culture that doesn't suit you.
Answer number two: As other posters have indicated, known public key algorithms are too slow to be of much use in encrypting large amounts of data. If you look at existing implementations, nobody does bulk encryption with a public key algorithm. Generate a random session key, send it to the other end encrypted with your public key algorithm, then use a stream cipher of your choice to do the bulk of the work.
This means, as hinted at above, that you don't just need an algorithm you need a protocol. Your protocol must address questions about how you generate your keys, how once side informs the other, who gets to generate them, how often (or if) they change, etc. It is possible to keep your protocol quite simple, but you need to at least think about such things.
Answer number three: In a word "modes". There are various ways to apply block encryption algorithms such that you can use them as stream algorithms. Because the public key algorithms are slow, this application will be slow, but it does work and is generally considered an OK cryptographic practice to apply the various modes where appropriate. So, what are the modes? What are their pros and cons? See chapter 9 of Bruce Schneier's Applied Cryptography.
If you are interested in this stuff, then you should really get a copy of Schneier's book and check it out. It's chok full O' cryptographic goodness. If your local bookstore doesn't have it, then fatbrain.com or your favorite online bookseller will.
One final thought. Messing around with crypto is a lot of fun, but it is harder than it might seem. There are a lot of implementation pitfalls that can render your crypto worthless or nearly so. When you are doing something really important, stick to existing algorithms and implementations.
I've been contemplating the same thing for a while, as my DSL reliability has been in the toilet. Can the rest of the net still find you when the DSL is out? If so, are you doing anything fancy with the routing or just relying on DNS to do the trick?
--mkb
You make an excellent point about key lifetimes, but the statement above is not correct.
If you want to know why, read Chapter 7 of Bruce Schneier's Applied Cryptography. The chapter is fairly short, and you could even read it in the bookstore if you don't want to buy the book. (Though I do recommend the rest of the book as well.)
The short version of the chapter is that beyond a certain key size, there simply is not enough time, matter and energy available to complete a brute-force attack before the sun swallows up the earth. Once the key is big enough, a break depends on finding a weakness in the algorithm itself or compromising the key in some other way. Other ways could include: physical theft, cameras, bribery, keystroke monitors etc.
Thus it requires a certain amount of trust in the receiving party that nothing has been tampered with. If you trust the recipient so much, why not just ask him/her to delete the message? If you trust the person so little, why are you sending the message in the first place?
I'll leave the NT/Unix flamewar to somebody else. I am tired of that one.
That issue aside, I can say that large companies are often not very price-sensitive w.r.t. big projects. A big development project will often end up saving millions of dollars, or producing millions of dollars in revenue. The people who sign the checks don't care about a difference of a few grand. They simply want to go with what they know will work.
In fact, corporate culture often runs in the opposite direction of price sensitivity. Many IT managers assume that you get what you pay for. If a product is cheap, it must not be very good. If it is free, it must be a piece of crap. Perl, Apache, and Linux are changing this perception, but only very slowly.
Inertia plays a big part as well. Nobody wants to change databases when an application works fine, so existing installations will tend to stay faithful to one vendor. We tend to think of Oracle as the incumbent, but there is a huge amount of stuff out there still in DB2. Byte magazine claims that 80% of the world's data is in DB2 databases.
Not that NT and Linux won't make inroads, but the target market for the high-margin vendors will be one of the last to fall. Cost and performance matter, but so does reputation.
Visio may be used extensively worldwide, but seeing it described with words like "incredible" makes me suspect that most Slashdot folk have not used a lot of other graphics software. Yes, Visio has a lot of features, but it is one of the klunkiest graphics programs I have ever seen.
For all the many faults of the Macintosh, it pretty much rules the graphic design space. If any Slashdot reader needs to do some serious graphics work, then spend some serious time using one of the many excellent graphics applications for the Mac. I say 'serious time' because just dabbling won't allow you to get past the mere fact that you are using a different OS. By putting in some real time, you should be able to get past the unfamiliarity factor and see some of the advantages.
I'm sure that Visio has some useful features that are really hard to find elsewhere, and anybody who is comfortable with it may as well keep using it. At the same time, if we spread the word far and wide that a klunky product is actually really good, then we make it that much less likely that Microsoft will ever improve the UI.
the author of this article doesn't realize why home consumers buy macs: simplicity. does he want to answer the tech support call when mrs. smith from Greendale, Ohio has to edit her inetd.conf?
;)
he also fails to recognize that people who use linux find it, not the other way around. there is a pre-requisite to using linux, and that's knowing how to use linux. all the marketing in the world won't teach this to the customer what to do at a login prompt.
there's also a mention here of the performance of linux far outpacing that of macos. sure, it does when you're benchmarking, but you're not comparing similar environments. the macos uses more overhead to provide user services in the GUI. if you loaded up a window manager which replicates EVERY feature of the macos GUI, i'm sure linux would slow down considerably. you're comparing apples to oranges (pardon the pun.
I do agree that Apple will have a surgence in popularity. With all the technological advancement we've been priveleged to witness, why should computers be problematic? Apple has always been focused on the user. while everyone else is talking about pre-emptive multitasking and protected memory, they've been neglecting the user in favor of the computer. windows is slowly getting easier, but the frustration-factor is still high for some of the most simple tasks. linux is getting easier slowly, but troubleshooting is still far beyond the average user.
apple started out with ease of use, and now with macos X they'll be adding the low-level features. they'll have the horses and the cart. i don't think it will be quite as easy as apple hopes; but a unified api set (carbon) shows promise. they'll sure beat windows2001 out the door.
mKb