Date: May 19, 2003, at BSI

Present:

David Cannon,
Joanna Farley,
Lois Goldthwaite,
Jon Hitchcock,
Andrew Josey,
Alan Lenton

The purpose of the meeting was to establish a position statement for the Linux Study Group meeting next week. The statement is attached to these minutes. These are some of the points which were brought up during the discussion:

We wonder what motivations, political or otherwise, prompted the formation of the Linux Study Group. It seems unlikely to have been an overture from the Free Standards Group! On the whole, the FSG seems wary of getting involved with ISO and the formal standards process.

There are some obvious advantages to Linux of acquiring formal ISO recognition: for one thing, some government or corporate procurement procedures mandate buying products which conform to one standard or another. The US federal government, for example, refers to standards rather than products in its requests for bids. LSB compliance has been mentioned in some purchase requisitions, and more and more commercial vendors are providing either the full Linux O/S or a compatibility layer.

The concept of standardizing Linux is absurd on the face of it. There is just too much of Linux. Furthermore, the LSB standard is not yet ready. It is currently at v1.3, and it is expected that stability won't be reached until 2.1. So it may be worthwhile for SC22 to endorse the standard, but not until the time is right.

Linux is moving to comply with Posix/Unix v2, but is not there yet. There are still a number of inconsistencies or extensions beyond the Posix standard. Perhaps it would be worth extending Posix to incorporate the most popular Linux extensions; this is something to look at for a future revision. Just as Unix is a superset of Posix, it would be good if Linux were also a superset; that would make things a lot easier for application writers.

If SC22 did adopt a Linux standard, would be it expected to show consistency with Posix? Is it OK for two ISO standards to contradict each other? LSB is a binary interface, whereas Posix lists compatibility hetween source level APIs. We are not sure whether ISO sanctions binary interface standards.

Linux is not the only operating system that should be considered. Standardisation efforts should look at other widely-used operating systems, such as FreeBSD. The value added by WG15 and the Austin Group is its experience in harmonizing the Posix and Unix standards. There is a need for someone to reduce (or better yet, eliminate) the conflicts between Posix and Linux standards. Perhaps it would make sense to extend the Posix standard to include the most popular Linux features.

There is a big push in the Linux community on i18n issues, but we are worried about duplication of work (there is more than one ISO body dealing with internationalisation) so recommend avoiding that area.

One area that the FSG has not tackled yet is a standard toolkit for development of portable, shrink-wrapped applications. There are utility programs that will flag a program if it isn't portable, but not much help for people trying to build portable applications. This is an area the LSB does not address yet. Issues that cause problems are the location of support files and the proper compiler and linker options, and feature macros to define, to achieve the widest possible compatibility.
 
 

Items for future action: we need to research which organizations do require standards compliance in their bidding procedures, and find out what kind of standard would most benefit (or influence) them. Some organizations that were suggested were universities (purchases over 50,000 pounds require extra red tape), and police departments.