Russ Herrold

Find out why you care about LSB, LANANA, FHS, LSB 5, LF, RPM5

Why do you (an attendee at FOSDEM) care to come to a lightning talk on:

    LSB, LANANA, FHS, LF, LSB 5, RPM5

Everyone who has been involved in FOSS knows that a new project needs to ship running code at once, or be passed over as 'not relevant', 'not ready', or plain old 'vaporware'. But everyone in FOSS also knows that once credibility is established by a project or a distribution, future updates and releases can have the leisure of a road-map, and not shipping 'until it is ready', because there is not the commercial pressure of a sponsoring company needing to push out potentially unfinished work to meet a marketing schedule. This also is expressed in the 'time boxed' vs. 'feature complete' release stabilization approaches. Agile methods and 'rolling releases' and the emergence of the tension between 'latest and greatest' vs. 'Enterprise' and 'LTS' permeates Linux-dom

The other common attribute of FOSS projects, is that the documentation seems always to be stale, always incomplete, and often wholly absent. How can a consumer of a project (individual or commercial) know what to rely on, or to 'write to'?

Fortunately, the ATT variant of Unix was produced by a designer, manufacture, and provider of telephone grade hardware, where manuals were not just 'nice to have' but also an essential part of the deliverables. The 'Unix wars', harsh as they were to adoption by end consumers of operating systems, also were 'fought in the trenches' of standards committee meeting rooms

And so POSIX and Unix-like expectations are quite well known, and so the need for formal testing for completeness and mandatory behaviors, and The Open Group carried some of the early hard work of writing and maintaining the test suites needed. Later the Linux Standards Base ('LSB') emerged as the reference standard, open and non-commercial, where a Independent Software Vendor, an end user, and a Distribution could each look for the needed interfaces, the certification of portability, and the benchmark of what to provide for inter-operability, in the Linux part of the 'nix world

LSB has been one of 'documenters', along with the minimal man page practice of Debian, and the Linux Documentation project ("LDP"). LSB was content to follow along and has a niche (perhaps not wanted by others, but so what?), and gravitated into sponsorship under the Linux Foundation ("LF)") in due course. Also, pulled into orbit was the Linux Assigned Names and Numbers Authority ("LANANA"), which recently has had ITS sub-project the File Hierarchy Standard {"FHS"} some need for extension of its specification to provide a way for package vendors, projects, and sub-parts from a vendor to obtain 'guaranteed uniquely managed' name-space paths in the file-system

The LSB has followed along, documenting expectation and tracking changes, so that expectations are explicit, tests are freely available, and that users of conformant software can count on portability as they move between distribution environments. Motif has pretty well died off, but Gtk and Qt came along; System V initscripts are slated for the dustbin as upstart and systemd fight it out. and so the recent update for LSB -- its new major version: 5.0 has been in beta, and went gold on (TBA)

So, come learn about how to write portable applications, or how to provide an environment which fosters uses of your project rather than another toolkit.

One of the items that was cut out of 'LSB 5.0 initial' due to incufficient resources, was an uplift of the RPM (LSB variant, which lacks triggers, and some other aspects which time has shown are needed -- ldconfig management and SELinux hooks come to mind). Also new compression schemes have come out of patent or emerged; new database stores for all the 'book-keeping' which a distribution's package manager needs. RPM5 has been exploring this space for a decade, and a companion presentation by Jeff Johnson has been proposed for FOSDEM 2014 as well, and will be briefly reprised here