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
