Good code does not speak for itself. If there is a braindead program you have to interface with, you need comments telling the future programmers why you are communicating with it in such a lame manner.
A good programmer can find WHAT any program does, but only comments can show WHY they do it. If a bad programmer writes WHY they are doing something, and then they do it poorly, a good programmer can come back and do it better. If a good programmer _has_ to write bad code because it's interfacing with another broken program, and DOES NOT include comments, another programmer will come in and write it the "right" way, and spend the next 2 years fixing it to work with the given program, until it looks just like the "bad" code it replaced.
Actually, they don't care about _either_ the latest whiz-bang feature or usability. They care about doing things the right way. This takes longer, but produces better results in the end.
That would make sense for a freshly launched version. Why? Galeon still has to load all of the Mozilla DLLs. Try opening about 20 windows and report back.
Re:From the "Reminds me of this classic prose" guy
on
Review: Harry Potter
·
· Score: 2
Has anyone heard about how Harry Potter is supposedly just a ripoff of another book about Larry Potter? Any information would be greatly appreciated.
Perhaps I am, can you name any names? Who makes money writing Free Software FROM the software? Not from support, speaking engagements, writing books, but from sales of the software?
*************
Why is this an issue? If the reason you are making money is because of the software, even if its not from direct sales, what's the problem?
Think about radio. You never have to pay the radio station anything for listening, but they still manage to make money off of the broadcasts. How? By selling advertising. So, who makes money from radio? Not from advertisements, sponsorships, or anything else, but by selling shows to individuals? Answer - nobody. It doesn't matter how the transaction comes about - if you make money because you write software, that's the whole point.
I think you're ignoring the people who do just this and make money.
You're also ignoring the fact that most development is done for in-house projects, which has no business reason for being closed. 90% of programmers are employed in this fashion.
I used to work with EWW, and he is truly a great guy. I am very happy for him that they got their issues worked out.
I also hope that the slashdot outage was because the T1 couldn't handle the load, and not because of the servers, because then they are probably blaming it on me now.
The truth is, you can somewhat accurately estimate project time. The problem is, few know how.
The thing is, you must get entirely through the design stages first. The design stages should include every screen as well as every possible error message, sub-screen, or whatever can pop up, as well as an outline of how the program flow will go. This takes a lot of time, but not quite as much as it sounds.
Once you have done the complete design, you can accurately make schedules. The problem is, most programmers put all error handling and messaging off as something that doesn't need to be designed. That's where the extra time comes in. If you know _exactly_ how the program flow is supposed to work, estimating time is easy. However, if you haven't finished the design stage, YOU DON'T KNOW WHAT YOU'RE PROGRAMMING, so, obviously, you can't estimate the time. So, with a _complete_ design, including all possible error conditions and actions to be taken, scheduling is not that hard.
The reason for fewer support technicians for the UNIX solution is that they are using thin clients. Therefore, there is only 1 machine to take care of. If there's a problem with the terminals, you just have a closet of spares - the user can grab them himself. No installation or setup is needed, you plug it into the network and it just works. So, yes, adminning a single machine is a part-time job.
To be fair Windows has terminal services which do the same thing, although I am unaware about how well it works.
It could be that they change the default pathway of the graphics calls for Quake, or that they skip things that are actually in the spec, but that Quake doesn't rely on. Or they could be ignoring error conditions that don't show up in Quake.
Why do you say that its not the kind of money that builds serious software? If it doesn't make anyone rich, but instead keeps them "only" consistently employed, I'm not crying over here. It might mean, *gasp*, that developers might have to _work_ for a living, rather than working for a few months and then retiring on the stock options. If they _can_ do that, it's probably from gouging the customer. Free Software is meant to empower the user through competition. Competition means that the margins aren't high. That's the nature of a free market.
Yes, but I don't see that happening on a large scale.
**********
It doesn't need to. Free software keeps people from needlessly re-inventing the wheel. They have access to everyone's code, so more time can be spent on doing new things rather than re-doing what other companies have done. This means that there will be fewer programmers, but I think that's good. Programming is a side task - it is only there to support the primary task. That means, the fewer people who are needed to do it, the better it is. So, it doesn't need to keep every current programmer employed, it just needs to continually spit out as much software as people need.
*************
But the average end-user doesn't care about enterprise software
*************
The end-user was not the case that the previous post was making, either. The previous poster was talking about enterprise software, where looking through manuals and code takes too much time. The end-user does not need to be able to just pick up the phone and have someone there. They can talk to others. They can read the manual. Or they can buy the boxed product.
This is entirely untrue. Enterprise rollouts of software almost always require a support contract, no matter how good the code is to begin with. In addition, customizations can be contracted as well. For example, RMS made money for years selling improvements to emacs. The improvements were open-source, but a company paid for them because the company wanted them. They paid the original developer to do it so that
a) it would be rolled back into the main distribution (this saves the company maintenance costs)
and
b) they know that the original developer has the best knowledge of the source code.
* There's no support built into the product. Yes, you can hire people to support it for you, but it's a seperate cost.
Oracle's "support" hardly qualifies. They rely _entirely_ on you being able to test it thoroughly yourself. Often fixes do not even address the problems you specified. Generally with Oracle Apps, you _have_ to have internal support. And, as you said, you can hire someone at a separate cost. So then it doesn't become a problem with Open Source in general, but rather of a specific product.
* Similarly, There is no warrantee of any kind. If it breaks, you have no one to complain to: "you get what you pay for."
Very, very few software companies have any real warranty. Again, you can purchase one.
* The programmers may suddenly decide they have no vested interest in continuing the project, or development may slow to a crawl (eg, mozilla), and there's nothing you can do about it.
Again, you can purchase it. Also, proprietary companies do this, too. Oracle Applications basically stopped sending us fixes on a regular basis when they decided they needed to push the next version (which takes at least 6 months to upgrade to). So, we either spend 6 months upgrading or have an unsupported product (it is _listed_ as supported, but that doesn't mean much).
I have yet to see a successful business model incorporating Open Source.
*********
Then you haven't been looking. Cygnus was profitable for years before being bought by RedHat. ADA Core Technology seems to be profitable (they've been around forever), Mandrakesoft was profitable except for a brief stint where they were run by some flashy US CEO. Penguin has jumped back into profitability. Many, many consultants spend their days developing open-source software for their clients.
I think that people are looking for a big company like Microsoft, but that's just stupid. You can be profitable with Linux, but you can't gouge people. It's kind of a built-in safeguard which prevents people from squeezing people out of money year-after-year. It doesn't prevent profit, just abuse.
You fail to recognize that in order to have that level of support with proprietary software, you have to have a similar support contract. So, you still save money, plus, because you have the source, you can shop around for supporters. For example, if I use a Macintosh operating system, Apple is really the only entity that can provide full support. Thus, if I use Apple, I am stuck with them even if they start screwing me on support costs. However, with open-source, I can use any willing company, because they can be provided with the source. Thus, if I don't like my supplier, I can tell him to screw himself and use a different one, without having to give my infrastructure a heart transplant.
I lost faith in Linux versioning and tree management a looooong time ago. I pretty much stick with distribution kernels these days. There are several things wrong with the current process, which could be fixed.
There needs to be OVERLAP of development kernels. For example, when 2.3 turned into 2.4-test, the 2.5 branch should have IMMEDIATELY shown up. That way, there is always a place for those who are good at doing new stuff and a place for those fixing what's there. This also greatly increases turnaround time. Also, Linus sucks at maintenance. He's good at development, but not at stabilizing and maintaining. Alan Cox is wonderful in that area. The _instant_ 2.3 became 2.4-test the reigns should have been handed to Alan Cox, to be released as 2.4.0 whenever Alan said it was ready. That way, Linus can spend his time dreaming up wonderful things and Alan can make it all work.
Anyway, I'd post this to LKLM, but I don't have time to be a kernel hacker myself.
No, they are stepping stones. He himself says that he hasn't written anything of use yet, but that he is building the foundation for it.
Each article goes into depth over a single API call, and compares the systems.
When he gets through about 10-15 articles, he will probably have something useful. Especially since he carefully explains his methodology and reasoning behind each step. This is much better than the traditional benchmarks which do 1 mammoth test and say X is better than Y. In this article series, he's going down and testing, in depth, feature by feature.
The nice thing about the tests is that all of the information about the tests are published, as well as the scope of what the test means (it has a very small scope of applicability). So, it's easy for anyone to reproduce the tests, and mention any problems with the tests.
Inter-process communication is an extremely important factor. Specifically, if your application uses a lot of it.
It's not the only thing, but it is pretty major.
If there's a bottleneck, that means poor scaling of applications to larger loads.
There's a lot that's not in the article, and the article itself says so. There's no information on sockets, RPC, or other means of IPC. That is all coming in future articles. However, it is silly to say that IPC speeds are not worthwhile.
Slashdot Mirror
Good code does not speak for itself. If there is a braindead program you have to interface with, you need comments telling the future programmers why you are communicating with it in such a lame manner.
A good programmer can find WHAT any program does, but only comments can show WHY they do it. If a bad programmer writes WHY they are doing something, and then they do it poorly, a good programmer can come back and do it better. If a good programmer _has_ to write bad code because it's interfacing with another broken program, and DOES NOT include comments, another programmer will come in and write it the "right" way, and spend the next 2 years fixing it to work with the given program, until it looks just like the "bad" code it replaced.
Actually, they don't care about _either_ the latest whiz-bang feature or usability. They care about doing things the right way. This takes longer, but produces better results in the end.
If you want X to run faster, renice it to -20
That would make sense for a freshly launched version. Why? Galeon still has to load all of the Mozilla DLLs. Try opening about 20 windows and report back.
Has anyone heard about how Harry Potter is supposedly just a ripoff of another book about Larry Potter? Any information would be greatly appreciated.
Perhaps I am, can you name any names? Who makes money writing Free Software FROM the software? Not from support, speaking engagements, writing books, but from sales of the software?
*************
Why is this an issue? If the reason you are making money is because of the software, even if its not from direct sales, what's the problem?
Think about radio. You never have to pay the radio station anything for listening, but they still manage to make money off of the broadcasts. How? By selling advertising. So, who makes money from radio? Not from advertisements, sponsorships, or anything else, but by selling shows to individuals? Answer - nobody. It doesn't matter how the transaction comes about - if you make money because you write software, that's the whole point.
I think you're ignoring the people who do just this and make money.
You're also ignoring the fact that most development is done for in-house projects, which has no business reason for being closed. 90% of programmers are employed in this fashion.
# developers ~3
# users ~8
Are your users always able to specify the requirements exactly before they see the system?
**
Generally, yes. That's the design process. They are seeing the system, because we actually draw pictures of it.
**
Does nothing ever change after the design stage - or it just that you don't allow change?
**
I allow change, it just comes with the understanding that it includes a schedule change. The necessary parts have to go back through design.
**
Do you never encounter problems when coding that were not foreseeable when designing?
**
Yes, but it is pretty rare. Obviously, no matter what, you can't forsee everything. But you can forsee most things.
**
To be honest if you take this approach I am surprised you ever get to the coding at all.
**
It takes a while, but the coding stage then becomes much, much shorter. By the time you get to it, all that's left is really typing.
I used to work with EWW, and he is truly a great guy. I am very happy for him that they got their issues worked out.
I also hope that the slashdot outage was because the T1 couldn't handle the load, and not because of the servers, because then they are probably blaming it on me now.
I miss you all!
The truth is, you can somewhat accurately estimate project time. The problem is, few know how.
The thing is, you must get entirely through the design stages first. The design stages should include every screen as well as every possible error message, sub-screen, or whatever can pop up, as well as an outline of how the program flow will go. This takes a lot of time, but not quite as much as it sounds.
Once you have done the complete design, you can accurately make schedules. The problem is, most programmers put all error handling and messaging off as something that doesn't need to be designed. That's where the extra time comes in. If you know _exactly_ how the program flow is supposed to work, estimating time is easy. However, if you haven't finished the design stage, YOU DON'T KNOW WHAT YOU'RE PROGRAMMING, so, obviously, you can't estimate the time. So, with a _complete_ design, including all possible error conditions and actions to be taken, scheduling is not that hard.
The reason for fewer support technicians for the UNIX solution is that they are using thin clients. Therefore, there is only 1 machine to take care of. If there's a problem with the terminals, you just have a closet of spares - the user can grab them himself. No installation or setup is needed, you plug it into the network and it just works. So, yes, adminning a single machine is a part-time job.
To be fair Windows has terminal services which do the same thing, although I am unaware about how well it works.
It could be that they change the default pathway of the graphics calls for Quake, or that they skip things that are actually in the spec, but that Quake doesn't rely on. Or they could be ignoring error conditions that don't show up in Quake.
Why do you say that its not the kind of money that builds serious software? If it doesn't make anyone rich, but instead keeps them "only" consistently employed, I'm not crying over here. It might mean, *gasp*, that developers might have to _work_ for a living, rather than working for a few months and then retiring on the stock options. If they _can_ do that, it's probably from gouging the customer. Free Software is meant to empower the user through competition. Competition means that the margins aren't high. That's the nature of a free market.
Yes, but I don't see that happening on a large scale.
**********
It doesn't need to. Free software keeps people from needlessly re-inventing the wheel. They have access to everyone's code, so more time can be spent on doing new things rather than re-doing what other companies have done. This means that there will be fewer programmers, but I think that's good. Programming is a side task - it is only there to support the primary task. That means, the fewer people who are needed to do it, the better it is. So, it doesn't need to keep every current programmer employed, it just needs to continually spit out as much software as people need.
*************
But the average end-user doesn't care about enterprise software
*************
The end-user was not the case that the previous post was making, either. The previous poster was talking about enterprise software, where looking through manuals and code takes too much time. The end-user does not need to be able to just pick up the phone and have someone there. They can talk to others. They can read the manual. Or they can buy the boxed product.
This is entirely untrue. Enterprise rollouts of software almost always require a support contract, no matter how good the code is to begin with. In addition, customizations can be contracted as well. For example, RMS made money for years selling improvements to emacs. The improvements were open-source, but a company paid for them because the company wanted them. They paid the original developer to do it so that
a) it would be rolled back into the main distribution (this saves the company maintenance costs)
and
b) they know that the original developer has the best knowledge of the source code.
You've obviously never used Oracle Applications :)
* There's no support built into the product. Yes, you can hire people to support it for you, but it's a seperate cost.
Oracle's "support" hardly qualifies. They rely _entirely_ on you being able to test it thoroughly yourself. Often fixes do not even address the problems you specified. Generally with Oracle Apps, you _have_ to have internal support. And, as you said, you can hire someone at a separate cost. So then it doesn't become a problem with Open Source in general, but rather of a specific product.
* Similarly, There is no warrantee of any kind. If it breaks, you have no one to complain to: "you get what you pay for."
Very, very few software companies have any real warranty. Again, you can purchase one.
* The programmers may suddenly decide they have no vested interest in continuing the project, or development may slow to a crawl (eg, mozilla), and there's nothing you can do about it.
Again, you can purchase it. Also, proprietary companies do this, too. Oracle Applications basically stopped sending us fixes on a regular basis when they decided they needed to push the next version (which takes at least 6 months to upgrade to). So, we either spend 6 months upgrading or have an unsupported product (it is _listed_ as supported, but that doesn't mean much).
I have yet to see a successful business model incorporating Open Source.
*********
Then you haven't been looking. Cygnus was profitable for years before being bought by RedHat. ADA Core Technology seems to be profitable (they've been around forever), Mandrakesoft was profitable except for a brief stint where they were run by some flashy US CEO. Penguin has jumped back into profitability. Many, many consultants spend their days developing open-source software for their clients.
I think that people are looking for a big company like Microsoft, but that's just stupid. You can be profitable with Linux, but you can't gouge people. It's kind of a built-in safeguard which prevents people from squeezing people out of money year-after-year. It doesn't prevent profit, just abuse.
You fail to recognize that in order to have that level of support with proprietary software, you have to have a similar support contract. So, you still save money, plus, because you have the source, you can shop around for supporters. For example, if I use a Macintosh operating system, Apple is really the only entity that can provide full support. Thus, if I use Apple, I am stuck with them even if they start screwing me on support costs. However, with open-source, I can use any willing company, because they can be provided with the source. Thus, if I don't like my supplier, I can tell him to screw himself and use a different one, without having to give my infrastructure a heart transplant.
This is rubbish. If it were true, someone would simply contribute that piece or fork the project.
I lost faith in Linux versioning and tree management a looooong time ago. I pretty much stick with distribution kernels these days. There are several things wrong with the current process, which could be fixed.
There needs to be OVERLAP of development kernels. For example, when 2.3 turned into 2.4-test, the 2.5 branch should have IMMEDIATELY shown up. That way, there is always a place for those who are good at doing new stuff and a place for those fixing what's there. This also greatly increases turnaround time. Also, Linus sucks at maintenance. He's good at development, but not at stabilizing and maintaining. Alan Cox is wonderful in that area. The _instant_ 2.3 became 2.4-test the reigns should have been handed to Alan Cox, to be released as 2.4.0 whenever Alan said it was ready. That way, Linus can spend his time dreaming up wonderful things and Alan can make it all work.
Anyway, I'd post this to LKLM, but I don't have time to be a kernel hacker myself.
The person who posted the article said it.
No, they are stepping stones. He himself says that he hasn't written anything of use yet, but that he is building the foundation for it.
Each article goes into depth over a single API call, and compares the systems.
When he gets through about 10-15 articles, he will probably have something useful. Especially since he carefully explains his methodology and reasoning behind each step. This is much better than the traditional benchmarks which do 1 mammoth test and say X is better than Y. In this article series, he's going down and testing, in depth, feature by feature.
The nice thing about the tests is that all of the information about the tests are published, as well as the scope of what the test means (it has a very small scope of applicability). So, it's easy for anyone to reproduce the tests, and mention any problems with the tests.
Inter-process communication is an extremely important factor. Specifically, if your application uses a lot of it.
It's not the only thing, but it is pretty major.
If there's a bottleneck, that means poor scaling of applications to larger loads.
There's a lot that's not in the article, and the article itself says so. There's no information on sockets, RPC, or other means of IPC. That is all coming in future articles. However, it is silly to say that IPC speeds are not worthwhile.