This is very premature. This was only testing ONE aspect of Windows vs Linux, which is not even used very much in the Windows world. This is meant to be an overall test of Windows vs Linux in performance, but the article is going to span over several weeks/months. Only after the series is finished will a good comparison be made. To say that Linux rocks just because it's pipes are faster means jack squat. What if Windows sockets are faster? What if Windows Disk IO is faster? What about Windows Asynchronous I/O? Eventually, this article series will answer such questions. However, this article ONLY answered the question of whose pipes are faster. Nothing else should be read into it.
You can't (to my knowledge) use script files to prevent or force RPM itself to do anything. For example, if you had glibc in your RPM, and you wanted to only install it if the other guy didn't have glibc, I don't think you can code that into your script file. Scripts do things like add users, edit config files, etc. They do not directly access the RPM database nor control that process.
Actually, I don't think that RPM has the necessary logic for this. For example, if I want to include glibc with my project, And they already have the same or later glibc version, it will just complain that it's already installed, won't it? I need it to be able to mark something as "install if they don't already have it" and then just be silent if its already there.
Actually, telling people how they can use technology effectively IS what an IT department is supposed to be doing. If your users are using applications incorrectly, it is the CIO's fault for either a) buying software without adequate business reasons or b) not training users adequately on the software being purchased. If they can be trained to create real databases in Access, they can create them anywhere, even if the tools aren't as pretty.
It is also a consultant's/CIO's job to analyze what is costing a business money in terms of its practices. Most companies spend stupid amounts of money on needless PowerPoint presentations. Scott McNeily foudn 9Gigs of PowerPoint presentations on the server, and had PowerPoint abolished. The next 3 quarters were record-setting profit-wise. Not necessarily cause and effect, but it shows how much it drains productivity.
I'm not saying "screw the user", I'm saying "train the user properly or don't give them the tool".
Most companies don't want control over development. They want a choice of products that have been developed. Subtle but important difference. Most companies want to be told ("sold") what they need. They want to "adopt best practices"
*************
Not quite true. After having decided upon a product, IS departments are very unlikely to change, so the ability to influence a change in the software it uses _is_ a major selling point. No, companies don't like to _develop_ software but they do like to have a say in development.
And, in this case, best practices seems to lean toward such an approach. You said $1 million isn't enough. Really? Are you sure? Most of it is there already. If we added $1 million dollars to the FSF's current budget, don't you think that would significantly impact development, especially since it seems to be steaming ahead just fine without it.
How about when you tell them that by simply donating money (which is tax-exempt) they can get software that conforms to their needs, not their competitors? And, in addition, there is no reason why it has to be such and amount. Why not $2,000? Would the company miss it? That money would go almost entirely to development. You would have control over the direction of development. That _does_ make sense. Exaggerating the claims and making a straw-man case does not invalidate the idea.
IMHO, no company is going to "pay" for something that they can get for "free".
************
They will if it allows them a say in what direction the development goes. Really, would a large company who usually pays a couple-hundred-thou a year in licensing costs really be bothered by paying a few thou instead to a charity? Tax-writeoff, etc., plus they get something out of it. Companies contribute to charities all the time, and this time they get something out of it.
In addition, the "support" model of software does work, too. It just, until now, has been run by utter fools. If you go out and sell a solution to a company, it costs them X dollars, and it saves them Y dollars, you don't even have to tell them that it's based entirely on free software. It doesn't really matter. You promised solution A for price X. You deliver, they benefit, everyone has a good day. The point is to solve business problems, not to "sell software". If you can solve a business's problems, you are worth your weight in gold.
2) Users should not be creating access databases. Unless you have _really_ technical users, they should just keep that info in spreadsheets and not delude themselves into thinking that they are database developers.
3) Some technologies (such as PowerPoint) tend to limit productivity more than enhance it. This would be an excellent time to outlaw such programs.
4) You could begin simply by mandating StarOffice for all _new_ installations or any upgrades. Don't move anyone, don't even change OSes, just make new purchases go to StarOffice. Then, perhaps, you might do the same thing for Operating Systems. It doesn't have to be a single step.
Actually this is a problem in MS Windows, too, except that the packaging format for MS Windows allows the packages to include their dependencies, too. That's really what RedHat needs to do - allow optionally-installed dependencies to be bundled in the same RPM. Kind of an RPM composed of several RPMs. Then you could distribute as a single file.
You don't need copyright to have paid programmers. In fact, only 10% of programmers write shrink-wrapped code. The rest do mostly in-house code. What is needed instead is either for the organizations to realize that they need to themselves help the overall infrastructure by putting programmers on it, or for them to simply to contribute money to the FSF or similar foundation for the development of the "common good" applications.
Actually, the reason that don't publish them online is both less and more sinister than that.
Simply, the reason they don't publish them online is that the same product may ship with multiple EULA's from different vendors. The one you get from Gateway is different than the one you get at the store.
True, but all the non-compiled languages don't use ELF (including normal byte-compiled Java). So I don't see how ELF would much relate to language independance.
**********
You have to pick a format, so why not pick a native one? There seems to be no need to develop a brand new format when one already exists for compiled languages.
I think the real key is data interaction -- that data structures created in one language are uniformly available to all languages. I don't think this really relates to ELF.
The reason it relates to ELF is that there needs to be a common format for storing type information in the object files. Remember, in the CLR, you can have Java extend a C++ class. This means that every class needs to have it's object information stored in the ELF file. In addition, there need to be standards for loading and initializing classes, as well as how they link.
I've always wondered what the point of the interpretted code was. Why not just make a new object format, or extend an existing one, but make it pure intel object code? You could even just mandate use a subset of it to make it easier to write an interpreter on non-Intel platforms. This seems like it would be much more effecient. The real gain from.NET is a common object format for OO languages, so why not just make ELF better?
The problem with this idea is that most real testing must be done in production. There is no way to simulate production exactly in testing. What really needs to happen is for more clueful IT managers to come onboard.
Am I the only one who thinks this is the absolute wrong thing to do? As vulnerable as IIS has proved as of late, completely rewriting any piece of software runs the risk of not only reintroducing old exploits but possibly generating new ones.
**********
Normally I would agree with you. However, if you write a program without much concern for security, it's hard to go back through and find security breaches. However, if you start from the beginning with a strong, well-defined set of security policies, it's fairly easy to do the right thing. Obviously, after a rewrite, it won't be as featureful and will probably have some rough edges, but I think it really is needed to have security designed in from the outset.
I have not seen very many solutions yet that defeat the very low tech terrorism that was used.
***********
I have a simple idea - arm everyone who gets on planes:)
In all honesty though, allowing people who have concealed handgun licenses and special training in pressurized cabins and who carry special bullets to carry their guns on the plane would probably do more to prevent terrorism than any amount of security. Then, the terrorists wouldn't know if they were the only ones on the plane that were armed. They also whouldn't know who they were.
It means that the EULA is just meaningless fiction, and not a contract that you bound yourself to.
Almost all EULAs are like that.
Even GPL.
Actually, this is incorrect. The difference between other licenses and the GPL is that other licenses remove freedoms that you would normally have, while the GPL adds to them. For example, under normal copyright, if a program was distributed without ANY license, I would have the freedom to a) examine it b) learn from it c) use it for any purpose d) make copies for archival purposes and e) anything else that fair use may allow. Past these things, you are restricted, even if no license is present. That is the basic copyright law. However, the GPL grants additional privileges that you don't normally get with copyright. Normal EULAs restrict the normal set of privileges, and thus many of us think of them as legal fictions. However, since the GPL actually expands them, you don't have to agree to the terms of the GPL until you decide you want the additional privileges. The text of the GPL also states this so you are aware of it. You only have to agree to the terms of the GPL for distribution, which is an allowance above and beyond the normal allowances under regular copyright law.
They had a charge of $33 million for 'amortization of goodwill', which basically means that they are spreading out the expense of buying Cygnus and other companies a year ago over several quarters. That $33 million-dollar loss was actually done last year, but they are spreading the loss over several quarters. Had they put the all of the costs of acquisition in that quarter's report, they would have reporte much, much fewer one-time costs. I am not sure about the other one-time costs, though, but I think it has to do with the layoffs that happened when they consolidated European offices.
...a tool that offers visual integration between Apache, MySQL and PHP without any line of scripting, and then I'll speak of a replacement for MS Access. Until then, it's all just for geeks.
If the form is going to be used by more than 1 person, it needs to be designed by geeks anyway. And then, the person can usually do just fine with a spreadsheet anyway. I've seen users try to make their own database. Then they want the techy people to 'web-enable' it. They think they've done the hard part by making the database. What they have usually made is a maintenance nightmare.
If there are any low-end Epson color printers, his users could be in for a big surprise.
Mine works fine.
Although he says that StarOffice is "fully compatible with Word/2000", other experience has shown otherwise.
Can you provide examples? I admit, I haven't been sent very complex documents, but it has handled anything anyone ever sent me.
It's pretty obvious this guy has never done a feasibilty study in his life. I give it a D-.
I agree, but I think he was mostly correct anyway. Not knowing the exact needs is a problem, but the given solution seems to provide for most basic needs.
I think the point is that what the techies need to know are what's given. What the CEO needs to know is the benefits, but the features are ultimately what's important, because that's where the rubber meets the road.
I could give you a list of 10 reasons to use it, but it would be pointless, because what really matters are the practicalities, which only your local geek can tell you. Yes, it may have a dictionary, but is it usable? Does it cause your printer to slow down unexpectedly? Will it modify your documents without permission?
Unfortunately, there are two major problems with the way IT is handled:
1) non-technical people make the decisions that technical people should be making
2) technical people have no idea what makes a good system
Since noone is trained on both sides of the issue, you end up with noone being able to make a sensible decision. Hence the number of installations of Oracle Applications in the world.
You should buy 1 Windows computer for all your specialized needs. Give it file access to the server, and run a good X server on there for access to the apps.
Slashdot Mirror
This is very premature. This was only testing ONE aspect of Windows vs Linux, which is not even used very much in the Windows world. This is meant to be an overall test of Windows vs Linux in performance, but the article is going to span over several weeks/months. Only after the series is finished will a good comparison be made. To say that Linux rocks just because it's pipes are faster means jack squat. What if Windows sockets are faster? What if Windows Disk IO is faster? What about Windows Asynchronous I/O? Eventually, this article series will answer such questions. However, this article ONLY answered the question of whose pipes are faster. Nothing else should be read into it.
You can't (to my knowledge) use script files to prevent or force RPM itself to do anything. For example, if you had glibc in your RPM, and you wanted to only install it if the other guy didn't have glibc, I don't think you can code that into your script file. Scripts do things like add users, edit config files, etc. They do not directly access the RPM database nor control that process.
Actually, I don't think that RPM has the necessary logic for this. For example, if I want to include glibc with my project, And they already have the same or later glibc version, it will just complain that it's already installed, won't it? I need it to be able to mark something as "install if they don't already have it" and then just be silent if its already there.
Actually, telling people how they can use technology effectively IS what an IT department is supposed to be doing. If your users are using applications incorrectly, it is the CIO's fault for either a) buying software without adequate business reasons or b) not training users adequately on the software being purchased. If they can be trained to create real databases in Access, they can create them anywhere, even if the tools aren't as pretty.
It is also a consultant's/CIO's job to analyze what is costing a business money in terms of its practices. Most companies spend stupid amounts of money on needless PowerPoint presentations. Scott McNeily foudn 9Gigs of PowerPoint presentations on the server, and had PowerPoint abolished. The next 3 quarters were record-setting profit-wise. Not necessarily cause and effect, but it shows how much it drains productivity.
I'm not saying "screw the user", I'm saying "train the user properly or don't give them the tool".
Most companies don't want control over development. They want a choice of products that have been developed. Subtle but important difference. Most companies want to be told ("sold") what they need. They want to "adopt best practices"
*************
Not quite true. After having decided upon a product, IS departments are very unlikely to change, so the ability to influence a change in the software it uses _is_ a major selling point. No, companies don't like to _develop_ software but they do like to have a say in development.
And, in this case, best practices seems to lean toward such an approach. You said $1 million isn't enough. Really? Are you sure? Most of it is there already. If we added $1 million dollars to the FSF's current budget, don't you think that would significantly impact development, especially since it seems to be steaming ahead just fine without it.
How about when you tell them that by simply donating money (which is tax-exempt) they can get software that conforms to their needs, not their competitors? And, in addition, there is no reason why it has to be such and amount. Why not $2,000? Would the company miss it? That money would go almost entirely to development. You would have control over the direction of development. That _does_ make sense. Exaggerating the claims and making a straw-man case does not invalidate the idea.
IMHO, no company is going to "pay" for something that they can get for "free".
************
They will if it allows them a say in what direction the development goes. Really, would a large company who usually pays a couple-hundred-thou a year in licensing costs really be bothered by paying a few thou instead to a charity? Tax-writeoff, etc., plus they get something out of it. Companies contribute to charities all the time, and this time they get something out of it.
In addition, the "support" model of software does work, too. It just, until now, has been run by utter fools. If you go out and sell a solution to a company, it costs them X dollars, and it saves them Y dollars, you don't even have to tell them that it's based entirely on free software. It doesn't really matter. You promised solution A for price X. You deliver, they benefit, everyone has a good day. The point is to solve business problems, not to "sell software". If you can solve a business's problems, you are worth your weight in gold.
1) It's a one-time cost versus an on-going cost
2) Users should not be creating access databases. Unless you have _really_ technical users, they should just keep that info in spreadsheets and not delude themselves into thinking that they are database developers.
3) Some technologies (such as PowerPoint) tend to limit productivity more than enhance it. This would be an excellent time to outlaw such programs.
4) You could begin simply by mandating StarOffice for all _new_ installations or any upgrades. Don't move anyone, don't even change OSes, just make new purchases go to StarOffice. Then, perhaps, you might do the same thing for Operating Systems. It doesn't have to be a single step.
Actually this is a problem in MS Windows, too, except that the packaging format for MS Windows allows the packages to include their dependencies, too. That's really what RedHat needs to do - allow optionally-installed dependencies to be bundled in the same RPM. Kind of an RPM composed of several RPMs. Then you could distribute as a single file.
You don't need copyright to have paid programmers. In fact, only 10% of programmers write shrink-wrapped code. The rest do mostly in-house code. What is needed instead is either for the organizations to realize that they need to themselves help the overall infrastructure by putting programmers on it, or for them to simply to contribute money to the FSF or similar foundation for the development of the "common good" applications.
Actually, the reason that don't publish them online is both less and more sinister than that.
Simply, the reason they don't publish them online is that the same product may ship with multiple EULA's from different vendors. The one you get from Gateway is different than the one you get at the store.
True, but all the non-compiled languages don't use ELF (including normal byte-compiled Java). So I don't see how ELF would much relate to language independance.
**********
You have to pick a format, so why not pick a native one? There seems to be no need to develop a brand new format when one already exists for compiled languages.
How would it help if there was a format for ELF when so many languages don't use ELF? Like, nearly all of them.
***************
Actually, all Linux-compiled languages use ELF. C, Java, C++, Objective-C, etc.
The reason it relates to ELF is that there needs to be a common format for storing type information in the object files. Remember, in the CLR, you can have Java extend a C++ class. This means that every class needs to have it's object information stored in the ELF file. In addition, there need to be standards for loading and initializing classes, as well as how they link.
I've always wondered what the point of the interpretted code was. Why not just make a new object format, or extend an existing one, but make it pure intel object code? You could even just mandate use a subset of it to make it easier to write an interpreter on non-Intel platforms. This seems like it would be much more effecient. The real gain from .NET is a common object format for OO languages, so why not just make ELF better?
The problem with this idea is that most real testing must be done in production. There is no way to simulate production exactly in testing. What really needs to happen is for more clueful IT managers to come onboard.
Am I the only one who thinks this is the absolute wrong thing to do? As vulnerable as IIS has proved as of late, completely rewriting any piece of software runs the risk of not only reintroducing old exploits but possibly generating new ones.
**********
Normally I would agree with you. However, if you write a program without much concern for security, it's hard to go back through and find security breaches. However, if you start from the beginning with a strong, well-defined set of security policies, it's fairly easy to do the right thing. Obviously, after a rewrite, it won't be as featureful and will probably have some rough edges, but I think it really is needed to have security designed in from the outset.
I have not seen very many solutions yet that defeat the very low tech terrorism that was used.
:)
***********
I have a simple idea - arm everyone who gets on planes
In all honesty though, allowing people who have concealed handgun licenses and special training in pressurized cabins and who carry special bullets to carry their guns on the plane would probably do more to prevent terrorism than any amount of security. Then, the terrorists wouldn't know if they were the only ones on the plane that were armed. They also whouldn't know who they were.
Almost all EULAs are like that.
Even GPL.
Actually, this is incorrect. The difference between other licenses and the GPL is that other licenses remove freedoms that you would normally have, while the GPL adds to them. For example, under normal copyright, if a program was distributed without ANY license, I would have the freedom to a) examine it b) learn from it c) use it for any purpose d) make copies for archival purposes and e) anything else that fair use may allow. Past these things, you are restricted, even if no license is present. That is the basic copyright law. However, the GPL grants additional privileges that you don't normally get with copyright. Normal EULAs restrict the normal set of privileges, and thus many of us think of them as legal fictions. However, since the GPL actually expands them, you don't have to agree to the terms of the GPL until you decide you want the additional privileges. The text of the GPL also states this so you are aware of it. You only have to agree to the terms of the GPL for distribution, which is an allowance above and beyond the normal allowances under regular copyright law.
They had a charge of $33 million for 'amortization of goodwill', which basically means that they are spreading out the expense of buying Cygnus and other companies a year ago over several quarters. That $33 million-dollar loss was actually done last year, but they are spreading the loss over several quarters. Had they put the all of the costs of acquisition in that quarter's report, they would have reporte much, much fewer one-time costs. I am not sure about the other one-time costs, though, but I think it has to do with the layoffs that happened when they consolidated European offices.
If the form is going to be used by more than 1 person, it needs to be designed by geeks anyway. And then, the person can usually do just fine with a spreadsheet anyway. I've seen users try to make their own database. Then they want the techy people to 'web-enable' it. They think they've done the hard part by making the database. What they have usually made is a maintenance nightmare.
Mine works fine.
Although he says that StarOffice is "fully compatible with Word/2000", other experience has shown otherwise.
Can you provide examples? I admit, I haven't been sent very complex documents, but it has handled anything anyone ever sent me.
It's pretty obvious this guy has never done a feasibilty study in his life. I give it a D-.
I agree, but I think he was mostly correct anyway. Not knowing the exact needs is a problem, but the given solution seems to provide for most basic needs.
I think the point is that what the techies need to know are what's given. What the CEO needs to know is the benefits, but the features are ultimately what's important, because that's where the rubber meets the road.
I could give you a list of 10 reasons to use it, but it would be pointless, because what really matters are the practicalities, which only your local geek can tell you. Yes, it may have a dictionary, but is it usable? Does it cause your printer to slow down unexpectedly? Will it modify your documents without permission?
Unfortunately, there are two major problems with the way IT is handled:
1) non-technical people make the decisions that technical people should be making
2) technical people have no idea what makes a good system
Since noone is trained on both sides of the issue, you end up with noone being able to make a sensible decision. Hence the number of installations of Oracle Applications in the world.
You should buy 1 Windows computer for all your specialized needs. Give it file access to the server, and run a good X server on there for access to the apps.
The article also said for the application server, it needs only be a 300Mhz computer with 80-256MB of RAM, which is pretty slim, too.