Slashdot Mirror
Linux Hamstrung by lack of standards?
Richard Finney wrote
in to send us a Yahoo/ZD article entitled
Linux hamstrung by lack of standards?
It mostly revolves around the Comdex stuff from monday, but
it has a few choice quotes, especially Larry Augustin predicting
that Linux will supplant NT in the server market this year,
comments about how Linux is growing in the corporate world,
and a little bit about the standards thing. Its odd that
they chose that title when the artice really doesn't
spend much time on the subject.
that there are so many of them!
Today, standards are a way similar to patents that companies are using to compete. I am not all that hot on Standards.
But what I think is important is Consensus...this is what standards were originally about. If we can get consesus about things, great. What we don't need is another "standard".
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
Well, other than System V, POSIX, Unix98, some BSD, net standards drawn up by the IETF, stuff like that.
But, you see, those don't count, at least not to journalists, as they're not =Microsoft= standards. The fact that the REST of the planet uses them is quite irrelevent. (For example, Multicast routing, IPv6, RSVP, QoS networking, etc, don't officially exist, as no Microsoft product is capable of supporting them. How can they exist? If MS doesn't use them, there can't be any standards, so clearly they don't exist.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
People interested in getting things done are just doing them and not whining. Hopkins FBI is sitting in my cubicle and CivCTP is sitting on my machine at home because it's the can-do's and not the cant-be-done's that drive Linux.
This person, anonymous and cowardly tho they may be, has hit on exactly the point of my comment. To hell with the corporations and their vaporous standards. Look around, see if anyone else is doing what you want to do, and, if there IS a standard, code to it. If not, hack, hack, hack, and fix it later. And, what the hell is this about lack of gui standards? Do any of the people who say things like this actually program? Do they know any 'developers?' Enough of the buzzwords! Shut up and code, or shut up and use, or shut up and write a damned RFC for your magical missing standards.
i browse at -1 because they're funnier than you are.
The question is can we make enough money to justify the development and support costs.
Also ask whether you can make enough off of all Unix versions. Most of the APIs a typical app would use in Linux are not Linux APIs but standard APIs supported on almost all Unices. If it compiles on Linux and you didn't make assumptions about things like byte order and word size and stuff like that, there's a good chance that, with minimal work, the same code will compile on Solaris, AIX, HP-UX, Digital Unix, BSD etc. etc.. Tools like GNU autoconfig can help by doing the scut-work of figuring out what is supported on the platform you're compiling on this time so that, instead of writing code to platform X, you write based on "of capabilities X, Y and Z that would do the job, which are available on this platform?" ( eg. does this OS support select(), poll() or both? ). The GNU tools are prime examples of code that is designed to compile on multiple platforms, as some of those programs support literally an insane number of CPU/OS/version combinations.
The next question is do we try and support all the distributions, or just one (Red Hat).
Again, often you won't care about distribution. For example, for the C library calls, the question isn't "Is this RedHat or Debian?", but "Do I use libc5 or libc6/glibc2?" and "Do I need glibc 2.1.x or will 2.0.x work?". If, for example, glibc 2.0.7 works, then the same program should run fine on any distribution that uses glibc2 including RedHat and I believe the latest Debian.
File locations may get trickier, but the FSSTND and FHS are good guides. Use config files or environment variables to specify file locations ( with compiled-in paths based on FHS/FSSTND as fallback ), or depend on Unix facilities ( eg. use PATH via exec[l|v]p() or file-existence search to find executables instead of hard-coding their location ) and you can make adapting to a distribution's layout a trivial matter of making sure PATH is set correctly and a few lines in a config file are edited appropriately.