Slashdot Mirror

Certainly a topic of much bile and hatred.

This will be long, hopefully you'll have the patience to read through it all. :)

One might ask at first why we even need standards. I'm sure a lot of you know just why, but there are plenty out there who honestly can't see why this is such a big deal to us. From their perspective it looks like we're childish arrogant bastards who are frothing at the mouth over nothing.

Quicky: Linux is not centralized. That is an amazing strength as well as a weakness as it allows Linux to be used for almost anything. Super-computer to clustering to desktop PC to 386 resurrector to PalmPilot OS. While these all do not have official distributions, it's part of the principle.

The problem here is that when one develops under one distribution, there's often no guarantee it will run on other distributions or even different versions of the same distribution. Keep in mind that most Linux software runs fine between these distributions. Software authors with lots of Linux experience generally write cross-Linux as well as cross-Unix code.

Standardization for hardened Linux developers would merely make the job easier. If it's easier to write it tends to get done faster, if it gets done faster the programmer has more time to experiment and debug (or not fail school or raise children or other equally important things :)

The maddening standards debates didn't begin until (to my knowledge anyway) commercial software developers saw an interest in Linux. Most of the times these Linux ports tend to be aimed at a specific distribution as well as a specific platform. This happens because "commercial" software developers usually don't have the time or energy to learn Linux well enough to write a proper port.

This isn't an issue about standardizing Linux. It's an issue of making Linux easier to learn and develop for. When I first picked up one of those cryptic text editors and COMMAND LINE based compilers, I had no idea how to write anything. Where are the threads? What the hell are signals? WTF is fork? Why the hell are there all these zombie processes? (How come my system is no longer usable? :)

I wasn't up to speed for at least 10 months. Granted I wasn't giving it my full attention and total dedication but you still get the idea. New Linux apps are about a year behind the Windows world, if ported. As Linus himself even said, the problem isn't that it isn't there. The problem is that it isn't documented well enough. Commercial software development isn't undertaken by skilled hackers and kernel tinkerers.It's taken up by people who want to finish the port and get paid and go home. If we want them to work for us efficiently, we need to provide them gobs of documentation and tutorials so they don't have to think more than necesary.

No I'm not calling all commercial developers idiots, but you can see where I'm coming from here can you not? When you take it in this light, the only standardization Linux really needs is cross-distribution collaboration. It's in every distributors' best interests to make their distribution compatible with the rest. We don't need a standards organization we have to pay to do it for us, nor do we need super commercial giants involved.

We succeed on globalized teamwork and cooperation. Forcing us to all conform to a standard is the opposite of this idealism. This is how the Corporate world tries to work. We shouldn't settle for that. There are better ways, and there's no reason for us to become stupid (stupid as in doing what's technically bad for the system) all of a sudden.

A standard base wouldn't be such a bad idea, but as many an editorial on freshmeat stated: The LSB will succeed on how little it defines, not how much it defines. (I probably junked that up, but the idea is the same). A standards organization is going too far, and the idea bothers me to no end. Not because of 'Linux Standards' and it's rather "misguided" methods of going about it, but rather because it's a technically bad idea. (tm)

I'll use the OpenGL Architectural Review Board as an example. The ARB is a group that meets every so often to discuss what happens to OpenGL. This sounds innocent enough, but it's current members are Microsoft, SGI, Evans & Sutherland, HP, IBM, Intel, and Intergraph. The fate of OpenGL is decided by these people. How would you feel if Linux's future was decided this way as well?

Couldn't you just picture Microsoft and several other Microsoft-controlled Linux haters becoming Linux Standards members and running Linux to the ground? I sure could.

The future of Linux will be decided by it's users. That's the way it has always been, and short of me being thrown in prison, that is how it shall remain.

An Operating System of the people, by the people, and for the people.

Michael Bacarella
Systems Administrator / Development
New York Connect.NET

Certainly a topic of much bile and hatred.

This will be long, hopefully you'll have the patience to read through it all. :)

One might ask at first why we even need standards. I'm sure a lot of you know just why, but there are plenty out there who honestly can't see why this is such a big deal to us. From their perspective it looks like we're childish arrogant bastards who are frothing at the mouth over nothing.

Quicky: Linux is not centralized. That is an amazing strength as well as a weakness as it allows Linux to be used for almost anything. Super-computer to clustering to desktop PC to 386 resurrector to PalmPilot OS. While these all do not have official distributions, it's part of the principle.

The problem here is that when one develops under one distribution, there's often no guarantee it will run on other distributions or even different versions of the same distribution. Keep in mind that most Linux software runs fine between these distributions. Software authors with lots of Linux experience generally write cross-Linux as well as cross-Unix code.

Standardization for hardened Linux developers would merely make the job easier. If it's easier to write it tends to get done faster, if it gets done faster the programmer has more time to experiment and debug (or not fail school or raise children or other equally important things :)

The maddening standards debates didn't begin until (to my knowledge anyway) commercial software developers saw an interest in Linux. Most of the times these Linux ports tend to be aimed at a specific distribution as well as a specific platform. This happens because "commercial" software developers usually don't have the time or energy to learn Linux well enough to write a proper port.

This isn't an issue about standardizing Linux. It's an issue of making Linux easier to learn and develop for. When I first picked up one of those cryptic text editors and COMMAND LINE based compilers, I had no idea how to write anything. Where are the threads? What the hell are signals? WTF is fork? Why the hell are there all these zombie processes? (How come my system is no longer usable? :)

I wasn't up to speed for at least 10 months. Granted I wasn't giving it my full attention and total dedication but you still get the idea. New Linux apps are about a year behind the Windows world, if ported. As Linus himself even said, the problem isn't that it isn't there. The problem is that it isn't documented well enough. Commercial software development isn't undertaken by skilled hackers and kernel tinkerers.It's taken up by people who want to finish the port and get paid and go home. If we want them to work for us efficiently, we need to provide them gobs of documentation and tutorials so they don't have to think more than necesary.

No I'm not calling all commercial developers idiots, but you can see where I'm coming from here can you not? When you take it in this light, the only standardization Linux really needs is cross-distribution collaboration. It's in every distributors' best interests to make their distribution compatible with the rest. We don't need a standards organization we have to pay to do it for us, nor do we need super commercial giants involved.

We succeed on globalized teamwork and cooperation. Forcing us to all conform to a standard is the opposite of this idealism. This is how the Corporate world tries to work. We shouldn't settle for that. There are better ways, and there's no reason for us to become stupid (stupid as in doing what's technically bad for the system) all of a sudden.

A standard base wouldn't be such a bad idea, but as many an editorial on freshmeat stated: The LSB will succeed on how little it defines, not how much it defines. (I probably junked that up, but the idea is the same). A standards organization is going too far, and the idea bothers me to no end. Not because of 'Linux Standards' and it's rather "misguided" methods of going about it, but rather because it's a technically bad idea. (tm)

I'll use the OpenGL Architectural Review Board as an example. The ARB is a group that meets every so often to discuss what happens to OpenGL. This sounds innocent enough, but it's current members are Microsoft, SGI, Evans & Sutherland, HP, IBM, Intel, and Intergraph. The fate of OpenGL is decided by these people. How would you feel if Linux's future was decided this way as well?

Couldn't you just picture Microsoft and several other Microsoft-controlled Linux haters becoming Linux Standards members and running Linux to the ground? I sure could.

The future of Linux will be decided by it's users. That's the way it has always been, and short of me being thrown in prison, that is how it shall remain.

An Operating System of the people, by the people, and for the people.

Michael Bacarella
Systems Administrator / Development
New York Connect.NET

The following is an editorial by Slashdot reader Michael Bacarella .

A large group of people don't understand the point of open source software. This editorial will attempt to settle one point that I would consider to be quite a valuable boon to the industry if practically all software was open source. While not all software should be open immediately since the original developer would like to define a clear direction for it first and perhaps even to keep some things secret to stay competitive, eventually, all software should be destined to go into the open source pool. This leaves a good impression on customers who will then end up taking an affection to your organization for being generous and it in return allows you to forsake maintaining software that you just wish you could get out of your hands. In addition, you aren't leaving this software abandoned as people will take it upon themselves to maintain the software you have given to the public if there is still a need for it. If my company were dependent on a certain software package, I feel that I would have more options at my disposal if when I paid for the software, I received the source to it as well, as opposed to getting software for free but without the ability to modify it to suit my needs. I see this as an easier idea to stomach as this happens to allow developers to profit off of their work and still do the "right thing" for the consumer.

Why is giving your customers the source to your work the right thing to do?

Suppose for a moment that you were the manager of a corporation or a class instructor. Now, let us go further and suppose that you need to supply your company/class with some reference material or perhaps instructions on how to do a particular job.

Example. You had to order books for your students to help them in their study of Nuclear Physics or instructions for your workers on how to manufacture your new product line.

Let's say, after purchasing these manuals or references and putting them into employment, you discover a horrible error in their text or perhaps you want to add some additional steps to the instructions which will help ensure safety for some of your workers. Imagine you wrote to the publisher and told them about errors you found or suggested an improvement to their texts, and the publisher says that they cannot do such a thing because you're the only one requesting these changes.

What would you do? I would instinctively remember not to order from these companies again and then go about correcting the errors in the text and make an addendum to the manuals.

A logical course of events. It is certainly a lot cheaper then ordering a completely new set of books, and you can use the rest of the otherwise perfectly adequate information.

Let's go one step further and imagine that you couldn't cross out the erroneous information or write anything on the paper, or that you couldn't copy it for that matter. The ink disappeared or the crossed out information un-crossed itself out, or an alarm sounded and you'd immediately get swept into a lawsuit for violating a copyright.

Changes that could make life easier.. illegal.

Kind of ridiculous wouldn't you say?

That's exactly what closed-source software is.

While not being life-threatening (in most cases) or dangerous, it could still theoretically cause damage in the form of burned out monitors or the loss of a database or virtually anything imaginable. (While rare, these kind of things do happen).

Even in practical use. Let's say you bought office software which you later discovered had a bug in it, a bug which didn't exist in the demo version of it (if you're lucky enough to have been granted a demo) that caused it to spit out an extra fives sheets of paper whenever you had something printed, or every so often, it'd crash whenever you tried to save a file.

You're stuck with faulty software that cannot be fixed except by those who have rights to do so, and you don't want to (or can't) buy an alternative package because of a budget. Quite far from the logical thing to do, since you have an otherwise fine software package that you could do wonders with, except for those few bugs that are pestering you.

What can you do?

You can write the publisher/distributor/developer and ask them to fix the error. In a perfect world, this would be an instant solution. In the real world the chances are that this will take longer than you would like and that some publishers won't even listen to you at all if you're the only one with a complaint. You have deadlines to meet and you simply don't have the luxury of buying alternative software packages, so you resume using that package hoping that bugs don't make things difficult and consequential.

This is not an efficient or stable work environment, and I'm sure no manager wants to have their employees go through this. Corporations fail to see that these problems could be easily avoided if you had access to the source code directly because it'd allow you to hire a programmer for a small fee (perhaps even free if you're crafty) to fix this problem. Almost every company that has a computer services division has one or two employees who have experience in programming.

Open source software allows you to contract a programmer, or temporarily re-assign an employee who can immediately go to work, fix the error, and get you back on track allowing you to continue using the software.

Suppose you're in the mood to experiment, or have a certain feature in mind that you saw in some other attractive package but aren't under budget or time to go out and experiment with new software. Let's say you want to support some file format so you can exchange work with the corporate credit department that uses a different software package. Perhaps you want the software to automatically backup to another server when the work is saved so that your employees don't have to be trained or bothered with it. Guess what? Now is the time to ask that programmer who did such a good job fixing all of your bugs if they would like to make a little extra cash or earn a good recommendation and add that feature!

This is why some major corporations have in-house software development, but for smaller companies, the cost of maintaining such a department is usually too great an expense to justify their existence. It'd be a lot easier to just hire someone under contract to fix the errors or make the enhancement, and then keep their information around so you can contact them if you need them again someday. If your software is fine for the next 8 months, you haven't been paying someone for 8 months of sitting around.

Closed source (most software out there) simply doesn't allow you to do these things, things that can benefit your company greatly. Software doesn't have to be this way, and it shouldn't be this way.

Open source software allows you to do all of the above. Developer's don't have to give the rights to their code away, just give people who pay for the software the chance to take matters into their own hands and fix their own problems if you're too busy to deal with it. Most developer's hate code maintenance, and spending the time to fix these bugs takes away from the time that could be spent in research and future development. In addition, they can keep good relations with their customer's because they aren't locked into a situation where you are their only hope for fixing their software problems. In addition, some customers will even send you bug-fixes so that you can integrate it into future versions, with very little work on your part.

I urge both users and developers to support open source products.

Some will criticize me for not promoting the radical view of free software as proposed by Free Software Foundation and the GNU General Public License. I fully agree with these views, and that the world would indeed be a better place if this software model was accepted and followed, but reality tends to have this effect of making the right choice not necessarily the best choice. This method, while still retaining the spirit of open source software is much easier for the business conscious to fathom, as it lets programmers keep the rights to their code and entitles them to traditional software profits, and software users still have a company backing their investments in the software products they depend on.

I feel a compromise must be met between the two schools of thought, and this certainly is a valid one. I would appreciate comments and questions on this model.

This variant of free software is better than no source at all. This at least is a step in that direction. The right direction.

The following is an editorial by Slashdot reader Michael Bacarella .

A large group of people don't understand the point of open source software. This editorial will attempt to settle one point that I would consider to be quite a valuable boon to the industry if practically all software was open source. While not all software should be open immediately since the original developer would like to define a clear direction for it first and perhaps even to keep some things secret to stay competitive, eventually, all software should be destined to go into the open source pool. This leaves a good impression on customers who will then end up taking an affection to your organization for being generous and it in return allows you to forsake maintaining software that you just wish you could get out of your hands. In addition, you aren't leaving this software abandoned as people will take it upon themselves to maintain the software you have given to the public if there is still a need for it. If my company were dependent on a certain software package, I feel that I would have more options at my disposal if when I paid for the software, I received the source to it as well, as opposed to getting software for free but without the ability to modify it to suit my needs. I see this as an easier idea to stomach as this happens to allow developers to profit off of their work and still do the "right thing" for the consumer.

Why is giving your customers the source to your work the right thing to do?

Suppose for a moment that you were the manager of a corporation or a class instructor. Now, let us go further and suppose that you need to supply your company/class with some reference material or perhaps instructions on how to do a particular job.

Example. You had to order books for your students to help them in their study of Nuclear Physics or instructions for your workers on how to manufacture your new product line.

Let's say, after purchasing these manuals or references and putting them into employment, you discover a horrible error in their text or perhaps you want to add some additional steps to the instructions which will help ensure safety for some of your workers. Imagine you wrote to the publisher and told them about errors you found or suggested an improvement to their texts, and the publisher says that they cannot do such a thing because you're the only one requesting these changes.

What would you do? I would instinctively remember not to order from these companies again and then go about correcting the errors in the text and make an addendum to the manuals.

A logical course of events. It is certainly a lot cheaper then ordering a completely new set of books, and you can use the rest of the otherwise perfectly adequate information.

Let's go one step further and imagine that you couldn't cross out the erroneous information or write anything on the paper, or that you couldn't copy it for that matter. The ink disappeared or the crossed out information un-crossed itself out, or an alarm sounded and you'd immediately get swept into a lawsuit for violating a copyright.

Changes that could make life easier.. illegal.

Kind of ridiculous wouldn't you say?

That's exactly what closed-source software is.

While not being life-threatening (in most cases) or dangerous, it could still theoretically cause damage in the form of burned out monitors or the loss of a database or virtually anything imaginable. (While rare, these kind of things do happen).

Even in practical use. Let's say you bought office software which you later discovered had a bug in it, a bug which didn't exist in the demo version of it (if you're lucky enough to have been granted a demo) that caused it to spit out an extra fives sheets of paper whenever you had something printed, or every so often, it'd crash whenever you tried to save a file.

You're stuck with faulty software that cannot be fixed except by those who have rights to do so, and you don't want to (or can't) buy an alternative package because of a budget. Quite far from the logical thing to do, since you have an otherwise fine software package that you could do wonders with, except for those few bugs that are pestering you.

What can you do?

You can write the publisher/distributor/developer and ask them to fix the error. In a perfect world, this would be an instant solution. In the real world the chances are that this will take longer than you would like and that some publishers won't even listen to you at all if you're the only one with a complaint. You have deadlines to meet and you simply don't have the luxury of buying alternative software packages, so you resume using that package hoping that bugs don't make things difficult and consequential.

This is not an efficient or stable work environment, and I'm sure no manager wants to have their employees go through this. Corporations fail to see that these problems could be easily avoided if you had access to the source code directly because it'd allow you to hire a programmer for a small fee (perhaps even free if you're crafty) to fix this problem. Almost every company that has a computer services division has one or two employees who have experience in programming.

Open source software allows you to contract a programmer, or temporarily re-assign an employee who can immediately go to work, fix the error, and get you back on track allowing you to continue using the software.

Suppose you're in the mood to experiment, or have a certain feature in mind that you saw in some other attractive package but aren't under budget or time to go out and experiment with new software. Let's say you want to support some file format so you can exchange work with the corporate credit department that uses a different software package. Perhaps you want the software to automatically backup to another server when the work is saved so that your employees don't have to be trained or bothered with it. Guess what? Now is the time to ask that programmer who did such a good job fixing all of your bugs if they would like to make a little extra cash or earn a good recommendation and add that feature!

This is why some major corporations have in-house software development, but for smaller companies, the cost of maintaining such a department is usually too great an expense to justify their existence. It'd be a lot easier to just hire someone under contract to fix the errors or make the enhancement, and then keep their information around so you can contact them if you need them again someday. If your software is fine for the next 8 months, you haven't been paying someone for 8 months of sitting around.

Closed source (most software out there) simply doesn't allow you to do these things, things that can benefit your company greatly. Software doesn't have to be this way, and it shouldn't be this way.

Open source software allows you to do all of the above. Developer's don't have to give the rights to their code away, just give people who pay for the software the chance to take matters into their own hands and fix their own problems if you're too busy to deal with it. Most developer's hate code maintenance, and spending the time to fix these bugs takes away from the time that could be spent in research and future development. In addition, they can keep good relations with their customer's because they aren't locked into a situation where you are their only hope for fixing their software problems. In addition, some customers will even send you bug-fixes so that you can integrate it into future versions, with very little work on your part.

I urge both users and developers to support open source products.

Some will criticize me for not promoting the radical view of free software as proposed by Free Software Foundation and the GNU General Public License. I fully agree with these views, and that the world would indeed be a better place if this software model was accepted and followed, but reality tends to have this effect of making the right choice not necessarily the best choice. This method, while still retaining the spirit of open source software is much easier for the business conscious to fathom, as it lets programmers keep the rights to their code and entitles them to traditional software profits, and software users still have a company backing their investments in the software products they depend on.

I feel a compromise must be met between the two schools of thought, and this certainly is a valid one. I would appreciate comments and questions on this model.

This variant of free software is better than no source at all. This at least is a step in that direction. The right direction.