LSB is much more than standard file system layouts. It allows you to build a common binary package (for a given processory architecture) that can be installed on any LSB-compliant distro (with that processor architecture). This is accomplished by building and linking your binary with import libraries from the LSB SDK, and commonly building an "LSB" RPM that only depends on the LSB package in an LSB-compliant distro.
So, for example, we distribute a product and make available four different binary LSB 3.0 RPM packages: "s390x" for 64-bit SUSE and RH "i486" for Intel 32 bit LSB compatible distos, including Debian based ones which can install via "alien" "PPC32" and "PPC64" for Power Linux distros (RH or SUSE) See: http://dovetail.com/downloads/coz/index.html (Under "Target System Toolkits") More info on porting an app to LSB can be found here: http://ldn.linuxfoundation.org/lsb/porting-lsb-demo So, LSB is really orthogonal to the OP reference to "common binaries" (aka FAT binaries), but in the context of Linux a FAT binary is not much use without what LSB brings due to the library and filesystem differences between different distros. IIMO, FAT binaries are easier to implement than what LSB does, even though I'm not sure that FAT binaries are a good solution. Makes more sense to me that a package manager / repository could just direct installation of the right binary for the right processor architecture. Kirk Wolf Dovetailed Technologies http://dovetail.com On Sun, Oct 25, 2009 at 6:10 PM, John Campbell <[email protected]> wrote: > LSB has, to my limited understanding, NOTHING to do with "Universal > Binaries". > > LSB, as I understand it, lays down a "standard filesystem tree" for > system configuration files and other basic services. > > Note that LSB means that the subdirectories under /etc will be > reasonably standard and any deviations will only be seen when the > hardware requires additional files. > > I suspect that LSB also influences the structure of the /dev tree, as > it does the /bin, /lib, /usr and /var file trees. > > It has been a long time since the days of the a.out header (as I first > saw in the original SLS distribution), COFF and the final decision to > adopt the ELF format (making the code and static data segments of a > binary program "block loadable" by the paging subsystem). > > I suspect that the "Universal Binary" of MacOS X duplicates static > data to handling the differing byte genders, but, really, the UB > capability for Apple isn't so bad since there are only two CPU > architectures to deal with. For a Linux distribution each binary > would need to hold a BUNCH of targets. > > Hmmmm... > > x86/32bit > x86/64bit > Itanium > ppc/32bit > ppc/64bit > sparc/32bit > sparc/64bit > s390/31bit > z/64bit > . > . > . > > Somehow I do not see a "Universal Binary" file as having a lot of > value in a system that has so many targets though having a Universal > Install HD-DVD *may* be the way to go. > > - soup > > On Sun, Oct 25, 2009 at 6:47 PM, Kirk Wolf <[email protected]> wrote: > > Does such an effort distract from LSB? To that point, what do listers > > think about LSB? > > > > Kirk Wolf > > Dovetailed Technologies > > http://dovetail.com > > > > PS> We have more than a casual interest in the future of LSB, since we > > currently offer products that ship in LSB form. Its not clear the the > > industry has or ever will fully embrace it. If not LSB, what chance > does > > something like this have? > > > > On Fri, Oct 23, 2009 at 9:21 AM, McKown, John < > [email protected] > >> wrote: > > > >> Interesting article, to me. Might be nice to have a single executable > that > >> runs on Intel/32 Intel/64, z/31, z/64, and p. Apparently the "data only" > >> portion would not be duplicated, only the executable code portion. Not > >> likely to happen, but interesting (again, at least to me). > >> > >> http://www.phoronix.com/scan.php?page=news_item&px=NzYyNQ > >> > >> http://icculus.org/fatelf/ > >> > >> > >> > >> John McKown > >> Systems Engineer IV > >> IT > >> > >> Administrative Services Group > >> > >> HealthMarkets(r) > >> > >> 9151 Boulevard 26 * N. Richland Hills * TX 76010 > >> (817) 255-3225 phone * (817)-961-6183 cell > >> [email protected] * www.HealthMarkets.com > >> > >> Confidentiality Notice: This e-mail message may contain confidential or > >> proprietary information. If you are not the intended recipient, please > >> contact the sender by reply e-mail and destroy all copies of the > original > >> message. HealthMarkets(r) is the brand name for products underwritten > and > >> issued by the insurance subsidiaries of HealthMarkets, Inc. -The > Chesapeake > >> Life Insurance Company(r), Mid-West National Life Insurance Company of > >> TennesseeSM and The MEGA Life and Health Insurance Company.SM > >> > >> > >> ---------------------------------------------------------------------- > >> For LINUX-390 subscribe / signoff / archive access instructions, > >> send email to [email protected] with the message: INFO LINUX-390 > or > >> visit > >> http://www.marist.edu/htbin/wlvindex?LINUX-390 > >> > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO LINUX-390 or > visit > > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > > > -- > John R. Campbell Speaker to Machines souperb at gmail dot > com > MacOS X proved it was easier to make Unix user-friendly than to fix Windows > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
