I think that like every other overhyped idea (java, WAP, P2P) this idea will find a niche and some companies will do very well with it. I know that there is a market for startup semiconductor design firms to buy time on an existing grid rather than having to purchase and manage a private grid in house that will merely turn electricity into heat 75% of the time.
I do not think that it will change the world and make great coffee.
Yep, it seems that at least two people on the Net know how to fight back, the old "hey, let's sign up the ripe-contact email address for gay porn magazines" routine.
I wonder if there are any legitimate consumers of gay porn email lists, or if they are exclusively used to annoy people?
More to the point: Debian is already marginalized to a certain extent. In the semiconductor industry, if a simulation or regression tool runs on linux, it runs on RedHat linux. A specific version of RedHat linux.
It is one of the first questions that technical support will ask: what version of linux is the tool running on? And if you answer incorrectly, you get a free trip to the sorry but that is not a supported configuration hang up. I am responsible for about a hundred linux boxes and none of them are Debian, for precisely this reason.
The real question is: so what? If the Debian developers are really as keen as everyone says they are, then it really doesn't matter -- they will keep coming up with technical innovations which will get tried, proven, and then absorbed into "more popular" distributions. Let Debian users be on the cutting edge, while those of us with real work to do can use the distilled and canned solutions to get on with our lives.
It is because software is supposed to bend to the will of the user, not the other way around. And that is why software is so feature-laden, so mandatorilly configurable.
If you wrote yourself a business app without configuration, you are dictating to your customers exactly how they will do the business they intend to use your software to do. That's great if your customer either does not do business in this area yet, or if they already do business the same way you expect them to.
But guess what! 99% of the target customers out there do or will want to do business differently!
For example? Let's pick something we can all agree on: source code management. Now how are we going to do business? Every shop will have a subtly different answer.
And that's the problem. Customers frequently don't know how they do business, and forcing them to articulate their current processes leads to them facing this unpleasant truth. Sometimes they tell you the wrong thing. Sometimes they deliberately tell you the wrong thing.
Sometimes management gets wind of all these neat metrics that the new system will be able to measure, and those get tacked on to the requirements sheet.
Sometimes there comes a requirement to seamlessly interface will all these legacy systems. Oh, and seamlessly sort, classify, access, and audit all the legacy data too.
You get the point.
The comparison with the auto industry is similarly bogus. The auto industry has a sharply restricted list of top level suppliers (Ford, GM, BMW), has the infrastructure to provide all routine supplies (like computer units, replacement hoods, etc), has a universal interoperability standard (the road), and a standardized operator interface.
Until the requirements for Business Software becomes simple and universal, the software fulfilling those requirements will never be either simple or universal.
As a developer of BOTH commercial and open source software, I think there is certainly scope for affirmitive action in software choice.
I disagree, and I disagree with the concept of government 'preferring' one type of software over another.
The government should define the requirements for software framed around it's actual needs:
price point
features
outsourced support (if necessary)
open file formats
source code requirements
...and then compare all comers. If the government really really needs source code to their applications, then it would be up to the vendor to say we can do that, but it will cost you $x or decide not to tender.
(Which indirectly raises another problem. There is no organization which will tender open source solutions to government RFP's -- and as soon as one shows up, it will have to be for-profit, which will make it evil in the views of all those who think everything should be free.)
The government should get the best tool for the job, and if Open Source is it, great -- and if Microsoft TaxMan 2003 is it, great.
It is in the public's interest to have an efficiently running government(*), no matter who gets paid for the software.
The planes from both Airbus and Boeing have "economy", "standard" and "luxury" seating configurations. Guess which configuration gets used by the airlines most.
This is because the pursuit of the lowest fares is driving service out of the business.
Think about it: you are going to fly somewhere. You can do it for $600, or $275. Which are you going to take? Which are you going to force your employee, flying on your nickel, to take? Right!
The result, airlines cut costs (and undoubtadly corners) in an effort to keep the seats filled, while playing silly games with travel agents, web sites, and walk-up to ensure that those who can be suckered into paying more, do so. Everyone has to play the same game, because price wins. They are driving themselves out of business in an effort to avoid being driven out of business.
Eventually, taking an airplane will be about as glamorous as taking the bus. And everyone will whine about missing the good old days, when you got a decent meal, planes ran on time, and the flight attendants were perky. They will forget that their airfare back then was three times what it is now, but will still wonder why there is no service and airlines are going out of business.
You have two programmers. One is just out of college, and costs you $x per year. One has been working in the industry for fifteen years, and costs you lets say $3x per year.
You give both programmers the same assignment.
Your young guy jumps on it and produces a tool to meet the assignments in two weeks. Your older guy takes four weeks. Who is more productive?
Your young guy's program is y lines. Your older guy's program is y/3 lines. Who is more productive now?
Your young guys's program has no documentation. Your older guy's program comes with complete internal commenting, a design document rationalized from the user requirements doc (which he pestered you for before he started), and a notation that he is waiting for you to assign a technical writer to the project so that the user documentation can be written. Who is more productive now?
Your young guy's program handles the data set in z seconds. Your older guy's program handles the data set in z/4 seconds. Who is more productive now?
Problems with your young guy's program require him to go back into the thing to fix them every so often. Most of the time, these seemingly small problems require him to spend a large amount of time poking through his program looking for the problem, and then re-architect large parts of the program in order to effect a fix. Meanwhile, your old guy's program has problems opened against it one tenth as often, and it takes him less time to locate the problem and make a fix. Now which programmer is more productive?
Both programmers leave. Which program would you want to be stuck with?
Most managers look at stupid metrics like number of lines of code produced, number of bugs fixed, that kind of thing. Younger programmers can crank crap out by the dumptruck, resulting in bugs by the dumptruck. And all that for a lower cost per year. But we all know that the more experienced programmer is the way to go, because he is actually completing more projects -- even though that metric cannot be accurately measured (since you practically never give the same assignment to two separate teams).
Managers hate this kind of reality, because it is impossible to graph on a powerpoint slide. They may not even know it intellectually, because all the metrics they measure are pointing to the wrong conclusion -- but as they do what the metrics encourage them to do, they wonder if there is a better way than having all these kids grinding all these hours producing all this crap.
You are correct, of course -- I had not thought of list servers. I think then the distinction would be having a program which read mail and did one or two things as opposed to having a fully-fledged scripting language embedded in your email client.
The whole thing was written more as a average-person-friendly rebuttal to the radio program than a detailed technical analysis.
I'm getting sick of the juvenile hair pulling which passes for morning
radio here in Ottawa these days, so this morning I was flipping around
during the drive to a client site. I landed on one of the CBC stations,
and they were talking about this uproar caused by the Calgary university
teaching a course which included a module on how to write viruses.
The controversy is that many of the anti-virus organizations say that
they will not cooperate with the university if they are writing
viruses. That it is irresponsible to give people the knowledge they
can use to release even more viruses out into the wild.
There were two interviews, one by someone against the course (and he
was keen to point out that the virus writing component was the only
component he objected to, and that the rest of the course was fine
by him) and by the head of the Computer Science division at the
university.
According to the opponent, the problem was that there were quite enough
viruses out there thank you very much and we did not need more people
with the knowledge of how to pump out more. This was countered by
the professor who pointed out that anyone who was in a fourth-year
accredited computer science program all ready had the knowledge needed
and could bang one out in a couple of hours. In other words, they
already have the knowledge to write the viruses, so what is the big
deal?
The point danced around by both gentlemen is that there is a dirty
little secret in the anti-virus community. The industry of virus
detection and removal is by definition a reactive rather than
a proactive process.
Let's back up here for a little background. When you are writing a virus
scanner, you only have two ways to detect a virus, which I describe as
the what it is technique and the what it does technique.
In other words, in using the first technique you recognize a virus
because you have already seen this virus before and therefore know exactly what it is. The
second technique is used to recognize a virus by what it does, virus-like
activities.
To put this into terms that everyone can understand, the what it is
technique is similar to the police knowing that John Q. Criminal is a mugger
because he's been convicted of mugging people in the past. The what it
does technique is similar to the police witnessing John Q. Criminal
hitting another citizen over the head and absconding with his wallet --
recognizing such behaviour as mugger-type activity, and reacting accordingly.
Back to our world of viruses. The what it is technique is a list
of signatures of viruses which have been seen before. A signature is
a string of some kind, along with some other data (such as the expected
location of said string in the suspect virus, the expected length of the
suspect virus, and so on). With this information you can categorically
say: "This is a virus." And all of us with virus scanners know about this,
because it is this information which is constantly being updated by our
vendors.
The what it does method of recognition is much much harder. It is
called heuristics, and it is supposed to recognize virus-like activity
so that the requirement for an up-to-date signature file is no longer needed.
To understand why this is so hard, consider this example. Suppose
that I am a virus, and I am going to propagate myself. What I will have
to do at some point is open a file to save myself so that I can be run
at a later date. The operating system hosting me (Windows, for example)
knows that I've asked to open this file. Now how is the virus scanner on
the same computer supposed to know that I'm about to write myself out
to that file, instead of being about to write out harmless Microsoft Word
data? You can't determine the intent behind the program's request
for system accesses -- and therefore you can not make intelligent decisions
as to if you should intervene, preventing the request
The real question is: what do you intend to do with your RedHat computer? The answer to that question will change which RedHat you will pick.
Consider the semiconductor industry. The vast majority of Linux computers we put in today are replacing or augmenting older unix vendor equiptment (like Suns and HPs). It is probably a compute farm system, and no one ever goes interactive with it. In this environment, you pick what your tool requires, because the tool is the only thing of any significance that you will run regularly on the computer.
Today, we have a lot of vendors who specify a particular revision of RedHat. If you have a problem with the tool, one of the first questions the support people ask is 'what rev of RedHat are you running?' And if you answer that question incorrectly, win a direct line to the 'sorry, that is not a supported configuration [click]' response. These are tools which cost thousands of dollars to license and support, the customer is not going to blink at the requirement for an additional $300 per system. That's chump change.
Since RedHat is moving to an accellerated retirement schedule, I am predicting that some (if not all) of these vendors are going to eventually specify an Enterprise edition of RedHat so that they are not constantly having to port their tool to the 'current' release. A three to five year stability program makes a lot of sense.
So the computer won't get the latest and greatest -- who really cares? The computer runs this tool, not the latest and greatest.
The only disturbing thing about this is that the vendors are being mysteriously silent on this matter. I've queried a number of SEs and reps about their companies plans to deal with RedHat stopping support for older revs of the OS, and to a man they plead ignorance. Whether that ignorance is genuine or due to a lack of corporate policy on their end, I don't know.
If, on the other hand, you merely have some desktop replacement computers -- heck, it takes about 30 minutes to set up a KickStart environment. Grab the latest ISOs and kick them all every four months!
Better would be languages which are self-documenting... you don't need to read the comments because the purpose is clear anyway.
I think that this won't happen, partially for Mr. Kringle's comment above, but mostly because there is a difference between what you do and why you did it (and again from why you didn't do it a different way). You can see function, but you can't necessarilly see the intent of the programmer. There are many times in my programs where a single line (often, less than 10 characters long) will result in several lines of comments explaining why it is done that way. That way, the poor boob who inheirits the job of extending/fixing the program (who is usually me) has a fighting chance of figuring out my intent, not just my procedure.
When the groceries you are delivering are the International Space Station, you need something reliable. Think about this: would you want to build a science station in another state, completely suported by nothing more than three Formula 1 cars? No, you use tried and true Chevy/Ford/Toyota trucks.
Yes, we absolutely should have an R&D vehicle program, but that program can't support other programs on top of it.
To this day, I'm very frugal with disk space. My home directory resides on a 60 gigabyte drive split into 3 20 gigabyte partitions, and I'm only using 17% of one partition right now.
Pardon that sound, it was my coffee going through my nose as I read that last sentance.
So if you are using 17% of 20Gb, that's almost 4Gb that you are using, right? If I can get all my home directories (mine, my wife's), all my system configuration info, etc backed up in less than a gig -- and let's not forget that this home directory has history going back almost ten years now -- who is being frugal?
Consider this: I might have more than one machine down, with more than one type of problem on the go, which means multiple users out of action.
Suppose I can fix all these problems, reading websites or changing memory modules -- but it will take me several hours per problem and/or machine.
Instead, with vendor support, I can call vendor A and say make it go, call vendor B and say make it go, have both sets of users up faster, all the while I am working on my own project work which doesn't fall behind schedule.
Yes, there's more in a cost of support contracts, but the savings is the reducing of our user's downtime -- it is cheaper to spend $5K on a support contract than it is to have a half-dozen ASIC engineers twiddling their thumbs for two days while I read websites.
Now I understand why Microsoft products have troubled security records..... I don't think I will be buying your products any time soon....
I do believe that sir is confusing the evil bit with a more appropriate bit for Microsoft products. This will be introduced in a RFC to be released late March 2004, entitled Incompetant Software Author Bit.
next time, at least check to see if it's an easy answer before you get belligerent and sarcastic.
Thanks for the help, I've been asking this for six months (ever since I discovered my web/email host would not accept email directly from my cablemodem ISP) and yours was the first which actually had enough information to make it work.
I did read the documentation, but it left me with the impression that I had to have an entry for each domain I was sending mail to (ie, that the username/password was domain dependant, not relay dependant).
It's moot anyways, because my ISP won't let me relay mail out when it is coming from my domain and going to a domain other than my ISP's, which leaves me in a catch-22 situation.
Since there's no reason for them to need to send it out *not* through the ISP as a relay host, the majority of these users are spammers or just ignorant. In the first case, it's good to block them. In the second, maybe they will get a clue.
Right, I'll bite.
Let's pretend I am an idiot who has a cable modem. And let's pretend that said cable modem issues an IP within the verboten rage. And now let's pretend that I have my own email domain completely unrelated to that of my ISP's, and that I use sendmail to send mail out.
With me so far?
Now, let's pretend that said ISP has implemented authentication requirements -- in other words, I must identify myself with a SMTP AUTH username and password before my ISP's server will accept my outbound mail.
So. How do I configure my sendmail so that it uses my ISP's server as a relay (SMARTHOST definition) but feeds it the magic username and password first?...
Slashdot Mirror
Arianne operates out of some nowhere place in Central America because:
I think that like every other overhyped idea (java, WAP, P2P) this idea will find a niche and some companies will do very well with it. I know that there is a market for startup semiconductor design firms to buy time on an existing grid rather than having to purchase and manage a private grid in house that will merely turn electricity into heat 75% of the time.
I do not think that it will change the world and make great coffee.
I wonder if there are any legitimate consumers of gay porn email lists, or if they are exclusively used to annoy people?
More to the point: Debian is already marginalized to a certain extent. In the semiconductor industry, if a simulation or regression tool runs on linux, it runs on RedHat linux. A specific version of RedHat linux.
It is one of the first questions that technical support will ask: what version of linux is the tool running on? And if you answer incorrectly, you get a free trip to the sorry but that is not a supported configuration hang up. I am responsible for about a hundred linux boxes and none of them are Debian, for precisely this reason.
The real question is: so what? If the Debian developers are really as keen as everyone says they are, then it really doesn't matter -- they will keep coming up with technical innovations which will get tried, proven, and then absorbed into "more popular" distributions. Let Debian users be on the cutting edge, while those of us with real work to do can use the distilled and canned solutions to get on with our lives.
It is because software is supposed to bend to the will of the user, not the other way around. And that is why software is so feature-laden, so mandatorilly configurable.
If you wrote yourself a business app without configuration, you are dictating to your customers exactly how they will do the business they intend to use your software to do. That's great if your customer either does not do business in this area yet, or if they already do business the same way you expect them to.
But guess what! 99% of the target customers out there do or will want to do business differently!
For example? Let's pick something we can all agree on: source code management. Now how are we going to do business? Every shop will have a subtly different answer.
And that's the problem. Customers frequently don't know how they do business, and forcing them to articulate their current processes leads to them facing this unpleasant truth. Sometimes they tell you the wrong thing. Sometimes they deliberately tell you the wrong thing.
Sometimes management gets wind of all these neat metrics that the new system will be able to measure, and those get tacked on to the requirements sheet.
Sometimes there comes a requirement to seamlessly interface will all these legacy systems. Oh, and seamlessly sort, classify, access, and audit all the legacy data too.
You get the point.
The comparison with the auto industry is similarly bogus. The auto industry has a sharply restricted list of top level suppliers (Ford, GM, BMW), has the infrastructure to provide all routine supplies (like computer units, replacement hoods, etc), has a universal interoperability standard (the road), and a standardized operator interface.
Until the requirements for Business Software becomes simple and universal, the software fulfilling those requirements will never be either simple or universal.
I doubt that the HURD will ever be ready for prime time. RMS obviously can't write an entire operating system (despite the evidence of EMACS).
I disagree, and I disagree with the concept of government 'preferring' one type of software over another.
The government should define the requirements for software framed around it's actual needs:
price point
features
outsourced support (if necessary)
open file formats
source code requirements
(Which indirectly raises another problem. There is no organization which will tender open source solutions to government RFP's -- and as soon as one shows up, it will have to be for-profit, which will make it evil in the views of all those who think everything should be free.)
The government should get the best tool for the job, and if Open Source is it, great -- and if Microsoft TaxMan 2003 is it, great.
It is in the public's interest to have an efficiently running government(*), no matter who gets paid for the software.
(* please ignore the oxymoron)
This is because the pursuit of the lowest fares is driving service out of the business.
Think about it: you are going to fly somewhere. You can do it for $600, or $275. Which are you going to take? Which are you going to force your employee, flying on your nickel, to take? Right!
The result, airlines cut costs (and undoubtadly corners) in an effort to keep the seats filled, while playing silly games with travel agents, web sites, and walk-up to ensure that those who can be suckered into paying more, do so. Everyone has to play the same game, because price wins. They are driving themselves out of business in an effort to avoid being driven out of business.
Eventually, taking an airplane will be about as glamorous as taking the bus. And everyone will whine about missing the good old days, when you got a decent meal, planes ran on time, and the flight attendants were perky. They will forget that their airfare back then was three times what it is now, but will still wonder why there is no service and airlines are going out of business.
You have two programmers. One is just out of college, and costs you $x per year. One has been working in the industry for fifteen years, and costs you lets say $3x per year.
You give both programmers the same assignment.
Most managers look at stupid metrics like number of lines of code produced, number of bugs fixed, that kind of thing. Younger programmers can crank crap out by the dumptruck, resulting in bugs by the dumptruck. And all that for a lower cost per year. But we all know that the more experienced programmer is the way to go, because he is actually completing more projects -- even though that metric cannot be accurately measured (since you practically never give the same assignment to two separate teams).
Managers hate this kind of reality, because it is impossible to graph on a powerpoint slide. They may not even know it intellectually, because all the metrics they measure are pointing to the wrong conclusion -- but as they do what the metrics encourage them to do, they wonder if there is a better way than having all these kids grinding all these hours producing all this crap.
The whole thing was written more as a average-person-friendly rebuttal to the radio program than a detailed technical analysis.
A more realistic test would involve having several crews come in every night while our candidate is sleeping and move 25% of the books around.
Consider the semiconductor industry. The vast majority of Linux computers we put in today are replacing or augmenting older unix vendor equiptment (like Suns and HPs). It is probably a compute farm system, and no one ever goes interactive with it. In this environment, you pick what your tool requires, because the tool is the only thing of any significance that you will run regularly on the computer.
Today, we have a lot of vendors who specify a particular revision of RedHat. If you have a problem with the tool, one of the first questions the support people ask is 'what rev of RedHat are you running?' And if you answer that question incorrectly, win a direct line to the 'sorry, that is not a supported configuration [click]' response. These are tools which cost thousands of dollars to license and support, the customer is not going to blink at the requirement for an additional $300 per system. That's chump change.
Since RedHat is moving to an accellerated retirement schedule, I am predicting that some (if not all) of these vendors are going to eventually specify an Enterprise edition of RedHat so that they are not constantly having to port their tool to the 'current' release. A three to five year stability program makes a lot of sense.
So the computer won't get the latest and greatest -- who really cares? The computer runs this tool, not the latest and greatest.
The only disturbing thing about this is that the vendors are being mysteriously silent on this matter. I've queried a number of SEs and reps about their companies plans to deal with RedHat stopping support for older revs of the OS, and to a man they plead ignorance. Whether that ignorance is genuine or due to a lack of corporate policy on their end, I don't know.
If, on the other hand, you merely have some desktop replacement computers -- heck, it takes about 30 minutes to set up a KickStart environment. Grab the latest ISOs and kick them all every four months!
I think we all hope that what ever it is, it has better things to do than that.
NIS meets this need handilly -- while simultaneously giving you a single point for managing your user accounts.
I think that this won't happen, partially for Mr. Kringle's comment above, but mostly because there is a difference between what you do and why you did it (and again from why you didn't do it a different way). You can see function, but you can't necessarilly see the intent of the programmer. There are many times in my programs where a single line (often, less than 10 characters long) will result in several lines of comments explaining why it is done that way. That way, the poor boob who inheirits the job of extending/fixing the program (who is usually me) has a fighting chance of figuring out my intent, not just my procedure.
I sure didn't.
When the groceries you are delivering are the International Space Station, you need something reliable. Think about this: would you want to build a science station in another state, completely suported by nothing more than three Formula 1 cars? No, you use tried and true Chevy/Ford/Toyota trucks.
Yes, we absolutely should have an R&D vehicle program, but that program can't support other programs on top of it.
Pardon that sound, it was my coffee going through my nose as I read that last sentance.
So if you are using 17% of 20Gb, that's almost 4Gb that you are using, right? If I can get all my home directories (mine, my wife's), all my system configuration info, etc backed up in less than a gig -- and let's not forget that this home directory has history going back almost ten years now -- who is being frugal?
Suppose I can fix all these problems, reading websites or changing memory modules -- but it will take me several hours per problem and/or machine.
Instead, with vendor support, I can call vendor A and say make it go, call vendor B and say make it go, have both sets of users up faster, all the while I am working on my own project work which doesn't fall behind schedule.
Yes, there's more in a cost of support contracts, but the savings is the reducing of our user's downtime -- it is cheaper to spend $5K on a support contract than it is to have a half-dozen ASIC engineers twiddling their thumbs for two days while I read websites.
I do believe that sir is confusing the evil bit with a more appropriate bit for Microsoft products. This will be introduced in a RFC to be released late March 2004, entitled Incompetant Software Author Bit.
Thanks for the help, I've been asking this for six months (ever since I discovered my web/email host would not accept email directly from my cablemodem ISP) and yours was the first which actually had enough information to make it work.
I did read the documentation, but it left me with the impression that I had to have an entry for each domain I was sending mail to (ie, that the username/password was domain dependant, not relay dependant).
It's moot anyways, because my ISP won't let me relay mail out when it is coming from my domain and going to a domain other than my ISP's, which leaves me in a catch-22 situation.
AuthInfo:smtp.isp.net "U:jrl" "I:jrl" "P:mypassword" "R:isp.net" "M:CRAM-MD5" ...which one is my username?
Now let's pretend that you have to do a SMTP AUTH with smtp.server.of.you.isp, username foo, password bar.
How do I do that?
Right, I'll bite.
Let's pretend I am an idiot who has a cable modem. And let's pretend that said cable modem issues an IP within the verboten rage. And now let's pretend that I have my own email domain completely unrelated to that of my ISP's, and that I use sendmail to send mail out.
With me so far?
Now, let's pretend that said ISP has implemented authentication requirements -- in other words, I must identify myself with a SMTP AUTH username and password before my ISP's server will accept my outbound mail.
So. How do I configure my sendmail so that it uses my ISP's server as a relay (SMARTHOST definition) but feeds it the magic username and password first?...
Any ideas?