linuxbase.org · Domains · Slashdot Mirror

Linux Standard Base by AndroidCat · 2005-01-17 02:09 · Score: 5, Informative · on LSB Submitted To ISO/IEEE

The LSB FAQ (for those whose first question was "What the heck is LSB?")

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA by NZheretic · 2004-12-02 15:03 · Score: 0 · on Red Hat, Novell To Package Xen

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA

Twelve Step TrustABLE IT:
Virtualised Linux Standard Base (VLSB)
in Virtual Demilitarized Network Zones (VDNZ)
from Trusted Build Agents (TBA)

Back in August 11, 1998, Microsoft's Vinod Valloppillil and Josh Cohen released a memorandum titled Linux OS Competitive Analysis: The Next Java VM?, in which they predicted that Linux would become ubiquitous as a services platform. However, the title of the paper could be even more prophetic.

Consider the following.

[1] It is well known that Linux is quite portable, in fact only NETBSD comes close to the number of hardware platforms supported.

[2] What is less well known is that the Linux kernel has even been ported to run on itself, as client for a virtual Monitor platform, and even to run virtualised on other operating systems including Win2K and XP.

[3] Other operating systems, such as BSD and Sun's Solaris can also use a compatbility layer to run applications compiled for Linux directly, without the need for virtualisation.

[4]The Linux Standard Base Mission Statement is to

To develop and promote a

set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

[5] The above standard also defines a generic subset of the standards for each hardware platform as a source level application interface. In fact for an application to be certified for the LSB it must be tested on two of the plaforms supported by the LSB, one chosen at random by the testing body. Following the standard, it's not that difficult a job to write portable C and C++ code : Write once, compile for each platfom.

[6] The GNU Compiler Collection's future GCC 4.0 Release Series now divides the task of compiling into two stages based around Static Single Assignment trees. It should be possible to use the new GCC front ends to compile each language into a SSA tree that represents the common generic subset of the Linux Standard Base: [5].The resulting SSA tree for a build could be dumped into files, analogous to Java's JVM intermediate format, and then complied to native code for the target platform: Write once, run everywhere.

Be it open or closed source, every binary or script you execute represents a risk. It is possible to introduce hostile code at any point along the build chain, before the point where the binary is checksummed and the result digitally signed.

[7] It is possible to use constraints built into any Linux or Unix like operating system to isolate and restrict what a binary executable has access to or can do. Even without employing SELinux's manditory access controls or chroot/jail'ed environments, it is possible to run a process under a different user identity and group identity. Unix servers have used this te

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA by NZheretic · 2004-12-02 15:03 · Score: 0 · on Red Hat, Novell To Package Xen

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA

Twelve Step TrustABLE IT:
Virtualised Linux Standard Base (VLSB)
in Virtual Demilitarized Network Zones (VDNZ)
from Trusted Build Agents (TBA)

Back in August 11, 1998, Microsoft's Vinod Valloppillil and Josh Cohen released a memorandum titled Linux OS Competitive Analysis: The Next Java VM?, in which they predicted that Linux would become ubiquitous as a services platform. However, the title of the paper could be even more prophetic.

Consider the following.

[1] It is well known that Linux is quite portable, in fact only NETBSD comes close to the number of hardware platforms supported.

[2] What is less well known is that the Linux kernel has even been ported to run on itself, as client for a virtual Monitor platform, and even to run virtualised on other operating systems including Win2K and XP.

[3] Other operating systems, such as BSD and Sun's Solaris can also use a compatbility layer to run applications compiled for Linux directly, without the need for virtualisation.

[4]The Linux Standard Base Mission Statement is to

To develop and promote a

set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

[5] The above standard also defines a generic subset of the standards for each hardware platform as a source level application interface. In fact for an application to be certified for the LSB it must be tested on two of the plaforms supported by the LSB, one chosen at random by the testing body. Following the standard, it's not that difficult a job to write portable C and C++ code : Write once, compile for each platfom.

[6] The GNU Compiler Collection's future GCC 4.0 Release Series now divides the task of compiling into two stages based around Static Single Assignment trees. It should be possible to use the new GCC front ends to compile each language into a SSA tree that represents the common generic subset of the Linux Standard Base: [5].The resulting SSA tree for a build could be dumped into files, analogous to Java's JVM intermediate format, and then complied to native code for the target platform: Write once, run everywhere.

Be it open or closed source, every binary or script you execute represents a risk. It is possible to introduce hostile code at any point along the build chain, before the point where the binary is checksummed and the result digitally signed.

[7] It is possible to use constraints built into any Linux or Unix like operating system to isolate and restrict what a binary executable has access to or can do. Even without employing SELinux's manditory access controls or chroot/jail'ed environments, it is possible to run a process under a different user identity and group identity. Unix servers have used this te

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA by NZheretic · 2004-12-02 15:03 · Score: 0 · on Red Hat, Novell To Package Xen

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA

Twelve Step TrustABLE IT:
Virtualised Linux Standard Base (VLSB)
in Virtual Demilitarized Network Zones (VDNZ)
from Trusted Build Agents (TBA)

Back in August 11, 1998, Microsoft's Vinod Valloppillil and Josh Cohen released a memorandum titled Linux OS Competitive Analysis: The Next Java VM?, in which they predicted that Linux would become ubiquitous as a services platform. However, the title of the paper could be even more prophetic.

Consider the following.

[1] It is well known that Linux is quite portable, in fact only NETBSD comes close to the number of hardware platforms supported.

[2] What is less well known is that the Linux kernel has even been ported to run on itself, as client for a virtual Monitor platform, and even to run virtualised on other operating systems including Win2K and XP.

[3] Other operating systems, such as BSD and Sun's Solaris can also use a compatbility layer to run applications compiled for Linux directly, without the need for virtualisation.

[4]The Linux Standard Base Mission Statement is to

To develop and promote a

set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

[5] The above standard also defines a generic subset of the standards for each hardware platform as a source level application interface. In fact for an application to be certified for the LSB it must be tested on two of the plaforms supported by the LSB, one chosen at random by the testing body. Following the standard, it's not that difficult a job to write portable C and C++ code : Write once, compile for each platfom.

[6] The GNU Compiler Collection's future GCC 4.0 Release Series now divides the task of compiling into two stages based around Static Single Assignment trees. It should be possible to use the new GCC front ends to compile each language into a SSA tree that represents the common generic subset of the Linux Standard Base: [5].The resulting SSA tree for a build could be dumped into files, analogous to Java's JVM intermediate format, and then complied to native code for the target platform: Write once, run everywhere.

Be it open or closed source, every binary or script you execute represents a risk. It is possible to introduce hostile code at any point along the build chain, before the point where the binary is checksummed and the result digitally signed.

[7] It is possible to use constraints built into any Linux or Unix like operating system to isolate and restrict what a binary executable has access to or can do. Even without employing SELinux's manditory access controls or chroot/jail'ed environments, it is possible to run a process under a different user identity and group identity. Unix servers have used this te

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA by NZheretic · 2004-12-02 15:03 · Score: 0 · on Red Hat, Novell To Package Xen

Twelve Step TrustABLE IT : VLSBs in VDNZs From TBA

Twelve Step TrustABLE IT:
Virtualised Linux Standard Base (VLSB)
in Virtual Demilitarized Network Zones (VDNZ)
from Trusted Build Agents (TBA)

Back in August 11, 1998, Microsoft's Vinod Valloppillil and Josh Cohen released a memorandum titled Linux OS Competitive Analysis: The Next Java VM?, in which they predicted that Linux would become ubiquitous as a services platform. However, the title of the paper could be even more prophetic.

Consider the following.

[1] It is well known that Linux is quite portable, in fact only NETBSD comes close to the number of hardware platforms supported.

[2] What is less well known is that the Linux kernel has even been ported to run on itself, as client for a virtual Monitor platform, and even to run virtualised on other operating systems including Win2K and XP.

[3] Other operating systems, such as BSD and Sun's Solaris can also use a compatbility layer to run applications compiled for Linux directly, without the need for virtualisation.

[4]The Linux Standard Base Mission Statement is to

To develop and promote a

set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

[5] The above standard also defines a generic subset of the standards for each hardware platform as a source level application interface. In fact for an application to be certified for the LSB it must be tested on two of the plaforms supported by the LSB, one chosen at random by the testing body. Following the standard, it's not that difficult a job to write portable C and C++ code : Write once, compile for each platfom.

[6] The GNU Compiler Collection's future GCC 4.0 Release Series now divides the task of compiling into two stages based around Static Single Assignment trees. It should be possible to use the new GCC front ends to compile each language into a SSA tree that represents the common generic subset of the Linux Standard Base: [5].The resulting SSA tree for a build could be dumped into files, analogous to Java's JVM intermediate format, and then complied to native code for the target platform: Write once, run everywhere.

Be it open or closed source, every binary or script you execute represents a risk. It is possible to introduce hostile code at any point along the build chain, before the point where the binary is checksummed and the result digitally signed.

[7] It is possible to use constraints built into any Linux or Unix like operating system to isolate and restrict what a binary executable has access to or can do. Even without employing SELinux's manditory access controls or chroot/jail'ed environments, it is possible to run a process under a different user identity and group identity. Unix servers have used this te

Re:From the article... by Tough+Love · 2004-11-21 10:43 · Score: 1 · on Linux Kernel to Fork?

where I work, the applications have to be specifically recompiled for each of the three versions of the Linux distribution currently in use.

That's what the Linux LSB standard addresses. Get it, study it, program to it.

Re:Article Short on details by carlmenezes · 2004-11-17 07:07 · Score: 1 · on Four Linux Vendors Agree On An LSB Implemenation

Well, apparently it's a kinda standard that specifies where our files are stored, what your default installation prefixes are, the filesystem hierarchy, where your init scripts are stored, etc...

basically, if I'm right, this means that once this is implemented, you'll find all your initscripts in /etc/rc.d/init.d on all conforming distros and you won't have to remember that one stores it in /etc/init.d while another stores it in /etc/rc.d/ etc etc...not just filesystem hierarchy, but a TON of other stuff...but you get the idea.

kinda a standard structure for Linux implementation.

You can get more specific info here :
LSB latest draft

actually... by softwave · 2004-11-17 03:45 · Score: 2, Informative · on Four Linux Vendors Agree On An LSB Implemenation

http://www.linuxbase.org/
LSB stands for Linux Standard Base. I quote rom the website:

What is the LSB Project?
The goal of the LSB is to develop and promote a set of binary standards that will increase compatibility among Linux systems (and other similar systems), and enable software applications to run on any conforming system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for such systems.

What LSB is by Anonymous Coward · 2004-11-17 03:45 · Score: 5, Informative · on Four Linux Vendors Agree On An LSB Implemenation

What is the LSB Project?

The goal of the LSB is to develop and promote a set of binary standards that will increase compatibility among Linux systems (and other similar systems), and enable software applications to run on any conforming system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for such systems.

What Does LSB Stand For?

The acronym LSB stands for Linux Standard Base. A key goal that led to the formation of the LSB project was to try to prevent the divergence of Linux-based systems, thus a name indicating base functionality for Linux. Note that the project prefers the use of the acronym LSB over the spelled-out Linux Standard Base to reduce the misconception that this is a Linux-only standard (see next question).

source: LSB faq

Was that difficult? No.

Re:LSB? by CrankyFool · 2004-11-17 03:43 · Score: 4, Insightful · on Four Linux Vendors Agree On An LSB Implemenation

My thoughts exactly -- the problem is that we don't have a well-defined idea of what acronyms at this point are well-known enough. You wouldn't see anyone bitching about not expanding AGP, PCI, or SCSI, but hell, I don't know what LSB is...

Well, I do now -- Linux Standard Base. See this link

Re:I'm still amused... by cold+fjord · 2004-11-12 10:35 · Score: 1 · on Where Is Sun Going With Linux?

The idea that a "Linux Stanard" could appear, against which Solaris could be compliant or certified, would strengthen Sun's hand.

It is called the Linux Standard Base Project. It strengthens Linux because without it commercial software vendors live in a sea of confusion over what Linux release to target, and testing becomes a nightmare. Commercial software is important because there is a lot more to do in the data center than just serving web pages. Without some sort of standard, the Independent Software Vendors will just gravitate toward one big Linux distro and create a new "Microsoft". If you are a software vendor and target "Bob's Garage Linux distro" instead of a LSB compliant distro, you are begging, just begging for trouble, and maybe bankruptcy.

The LSB is moving toward the POSIX / Open Group standard, which it a good thing. It helps Linux integrate into standards based and compliant environments. It also helps to reduce the "not better, just different" problem that Linux has had. It also reduces training and operations costs.

Now, nothing says you have to use LSB compliant distros, especially if you don't rely upon commercial software. But, I would think twice before I headed down that path with a company or data center minus some specific exceptions.

Re:United Linux by Lussarn · 2004-11-12 02:46 · Score: 2, Informative · on United Linux: Two Years Later

Unitied Linux was not an grassroot efort like Linux standard base. This are the one to follow for more strict standards.

LSB by danormsby · 2004-11-12 02:07 · Score: 5, Interesting · on United Linux: Two Years Later

My big hope for United Linux was that if I created a binary it would work under all x86 versions of Linux.

I'm now hoping Linux Standard Base 2.0 will really take off.

Anyone can complain by Anonymous Coward · 2004-11-04 15:58 · Score: 2, Insightful · on Maddog on the State of Linux

it takes an entity with vision to do something.

I would have liked to hear more details in this interview on how the LSB project is going and the other activities going on at the Free Standards organization since Jon is on their Board of Directors.

Re:Linux Gaming, In Summary by Atzanteol · 2004-10-04 08:56 · Score: 3, Informative · on Linux GPU Performance

I believe that's what the Linux Standards Base people are trying to fix. I've spoken to them at Linux world. Their goal is to eventually be able to have developers say "This program can run on any distro LSB1.0 compliant."

Re:Let's stop breaking Linux up. by drinkypoo · 2004-09-16 07:36 · Score: 1 · on Novell to Help Port Applications to Linux

Why yes, we probably should.

Re:Filesystem Hierarchy by Lodragandraoidh · 2004-09-15 06:01 · Score: 1 · on Two Years Before the Prompt: A Linux Odyssey

To quote the filesystem hierarchy verbatum:

Chapter 4. The /usr Hierarchy

Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.

Large software packages must not use a direct subdirectory under the /usr hierarchy.
Requirements

The following directories, or symbolic links to directories, are required in /usr.

Directory Description
bin Most user commands
include Header files included by C programs
lib Libraries
local Local hierarchy (empty after main installation) [my emphasis]
sbin Non-vital system binaries
share Architecture-independent data

...

/usr/local : Local hierarchy

Purpose

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

So, /usr/bin would be where the distribution deposits user commands, or a package updates said commands, whereas /usr/local/bin is left for the administrator(you) to put additional software added after installation that is not part of the regular distribution.

As for /opt:

/opt : Add-on application software packages

Purpose /opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name.

So, /opt is used for add-on packages whereas /user/local would be the target for the output of such packages - if not part of a regular distribution; as mentioned above, if the package updates an existing part of the distribution in /usr, then it can put it in the normal location (instead of /usr/local). This is why you have to be careful to grab the package from the same distribution - because, by definition, certain assumptions are being made by the distributors that may be different from that of another. This is also good - because it allows wiggle room for a distribution to extend the directory structure.

As a matter of policy, I install all non-distribution packages/builds into /usr/local. This avoids any conflicts, and makes backing up and restoring my stuff easy (tar -cvf usrlocal.tar /usr/local) - not to mention, I know where to look when there is a problem with an app. System upgrading and restoration is as easy as sftp'ing that tarball to another machine, then loading the new OS, and restoring the tarball.

Finally, the Linux Standard Base is an attempt to close the doors on areas of paticular contention. The LSB states, among other things:

An LSB conforming implementation shall provide the mandatory portions of the filesystem hierarchy specified in the Filesystem Hierarchy Standard (FHS) 2.3 (FHS), together with any additional requirements made in this specification.

Re:Where's the community? by nadamsieee · 2004-09-13 09:15 · Score: 1 · on Linux Standard Base 2.0 released

The LSB already has a set of test suites, but my question is "why aren't there any certified community distros" not "what would be an ideal way to get a community distro certified".

OLD NEWS by Anonymous Coward · 2004-09-13 08:40 · Score: 1, Informative · on Linux Standard Base 2.0 released

This spec was released August 30th, over 2 weeks ago.

Mentioned in WSJ Today by jhoffoss · 2004-09-13 05:28 · Score: 2, Informative · on Linux-only POWER5 server From IBM

This was mentioned in an article in the Wall Street Journal today. The article is regarding vendor-backing of LSB2. Near the end, the WSJ stated this product is meant to compete with Sun and HP workstations. Link to related story, as WSJ's requires subscription services.

What has Red Hat given to the Linux community? by petrus4 · 2004-08-21 04:14 · Score: 5, Informative · on Red Hat Walks The Linux Tightrope

Hmmmmm, let's see...

1. RPM. Read the Linux Standards Base documents?
2. Anaconda, the install/setup program.
3. Kudzu, the hardware detection system used by Knoppix and others.

I could continue, but I think those three on their own more than justify the company's existence, if nothing else.
While I will admit that as an overall distribution I was not overly enamoured of Red Hat 9, RH have contributed solutions to a number of vexing problems for us, and also carry on a very active development effort at sources.redhat.com.
I'm also detecting some of the usual commie whining (No, I don't think OSS is communist, but this is) about a company that's daring to actually make a large profit here...as if every company purely by virtue of its existence had to inevitably emulate Microsoft's bad behaviour. However, it might behoove you next time to be a little more sure of your facts before you start bitching.

Re:Debian by GammaTau · 2004-08-19 18:02 · Score: 1 · on KDE 3.3 Officially Released

Apart from the whole Free/non-free issue for documentation and firmware (or at least my understanding is that firmware is the source (oops, bad pun) of the other issues), I don't know of any other major plans for etch which could cause a long release cycle?

There are some plans for multiarch support. As far as I understand the issue, it would require modifications to all library packages but I don't know how big task it will really be.

Re:Very long list by 4of12 · 2004-08-18 02:58 · Score: 1 · on Complete List of Bugs Fixed in SP2

you just put a .appname folder and put the config files in there

In the old days it was enough for most applications to have

$HOME/.appnamerc ./.appnamerc

or, for real short configuration, storage in an environment variable as

APPNAME="specifications"

and perhaps have system-wide utilities configured using

/etc/appnamerc

where the files were simply full of Name = Value specifications.

Now, though, a lot of applications like to manage not just configuration settings, not just per-user configuration settings, but things like cached data, temporary files, lock files, serialized objects, network handles, etc.

It's a tough problem to solve, but you'd prefer that the best solution be intuitive and followed by most applications.

Has the LSB come out with any recommendations on this topic?

Someone might need to come up with a MetaConfig facility to oversee the diverse particular solutions. The extra layer of abstraction might add complexity, but potentially could simplify things for most people.

I'm not even sure it's ludicrous for an application to have its own filesystem. That is, in the same way that the kernel exposes things through /proc , user space applications might like to manage settings in /application or something like that, but with provision for multi-user systems, preserving state if need be, etc.

Re:American stupidity or political correctness ? by tepples · 2004-08-13 16:21 · Score: 2, Interesting · on Internet Publishing Can Pay Off

Under this analogy, wouldn't female dogging about deviations from an English "standard" correspond to female dogging about deviations from specifications such as Single UNIX, LSB, or GNOME HIG?

Re:Then you can't buy a one-handed keyboard for $2 by Minwee · 2004-08-11 02:29 · Score: 4, Informative · on A One-Handed Keyboard For $25

Yeah. "Some Blogger". What does this... whassisname... Bruce Perens guy know about geek culture, free software, and all that? I mean really now. What did he do? Write the Open Source Definition? Found the Linux Standard Base, Open Source Initiative, and Software in the Public Interest? Write widely used software and libraries? Spend eighteen years at Pixar and the NYIT Computer Graphics Lab, then two years as Senior Global Strategist for Linux and Open Source at HP?

It seems they let just about anybody post to Slashdot these days.

Re:Centralized administration by Zeddicus_Z · 2004-08-10 01:56 · Score: 1 · on Microsoft Developing Linux Policy, Plan of Attack

If Linux distros could offer a consistent config file format (Pick one. Seriously.), some form of config inheritance (eg load /etc/defaults/[someconfig], then /home/username/.config/[someconfig], then /etc/overrides/[someconfig]) and lockdown (think KDE's kiosk), that would help a lot. Yes, I understand that this is almost impossible given the nature of Linux distros as assemblies of independenly developed software, but nonetheless this would be awfully nice.

cfengine

LSB

Re:*cough*AD*cough* by Anonymous Coward · 2004-08-10 01:54 · Score: -1 · on Microsoft Developing Linux Policy, Plan of Attack

If Linux distros could offer a consistent config file format (Pick one. Seriously.), some form of config inheritance (eg load /etc/defaults/[someconfig], then /home/username/.config/[someconfig], then /etc/overrides/[someconfig]) and lockdown (think KDE's kiosk), that would help a lot. Yes, I understand that this is almost impossible given the nature of Linux distros as assemblies of independenly developed software, but nonetheless this would be awfully nice.

cfengine

LSB

All your Linux Standard Base... by tepples · 2004-08-01 04:01 · Score: 5, Interesting · on Can GNU Ever Be Unix?

GNU/Linux seems to be evolving as its own standard

And this standard is called LSB.

Yes, we DO have cross-distro RPMs... by WebCowboy · 2004-07-12 05:07 · Score: 1 · on URPMI For Fedora Core 2

...it is part of the Linux Standard Base and other standards of the Free Standards Group. The problem is that the standards have not been widely adopted enough. Perhaps that will change over time, particularly once LSB 2.0 is released in its final form. Presently, a few distros (Mandrake for one) are already LSB compliant and should properly install LSB-compliant RPMs regardless of the source. The drawback is that this compatibility is generally "bolted on" by installing--you guessed it--a distro-specific RPM.

RPM has been selected as the standard packaging format for LSB, and as the standard has evolved cross-distribution issues have been addressed. This had always included advocating adherance to the Filesystem Hiearchy Standard (FHS) and now includes things such as a universal package naming standard and standard implementation of printing systems. Those are among the most notorious of cross-distro difficulties we have to contend with right now.

Whatever you think of the RPM format, it serves its purpose quite well, and it is a standard. If Fedora and Mandrake and others start to work together on interoperable solutions to managing RPMs in combination with increasing support for LSB then it would mean a huge advancement in the effort to bring about widespread Linux adoption.

Re:FreeBSD is an OS, Linux isn't.... by harikiri · 2004-06-14 01:38 · Score: 4, Informative · on FreeBSD, Stealthy Open Source Project

Nvidia has FreeBSD drivers available. However for ATI drivers, there still remains a need for people to visit the Linux Driver feedback page and ask for FreeBSD support.

As both a FreeBSD user and Gentoo user, I think the best description would be that Gentoo is BSD for Linux users. As a humourous aside, some friends have also started describing Gentoo as "ricenix: 2Fast2Optimized". ;-)

Gentoo is laid out fairly logically (no idea if it follows the Linux Standards Base though). The main benefit is the total control you gain over your installation - much like you gain with BSD (hence, BSD for Linux users). Though it is achieved through the remarkable Portage package management system, vs FreeBSD which is a wholly maintained o/s, with a very large "ports" system.

The only thing that keeps me from using FreeBSD on my workstation is that I do play some games on Linux, and write software to support game playing on a local Australian gaming network. For those that don't need the fluff that's supported on Linux (games being a primary example), almost everything else is available under FreeBSD. But to save you extra work, Gentoo is probably the way to go (easy to manage once installed through portage).

L in LSB not necessarily for Linux by tepples · 2004-06-05 11:36 · Score: 1 · on GoboLinux Compile -- A Scalable Portage?

I think you didn't read what the first letter in 'LSB' stands for - Linux

Not exactly. Like Win32, LSB is a set of application binary interfaces, one for each of several CPU architectures. Any system running on a supported architecture can implement an LSB compatibility layer, just as Wine implements Win32 on select operating systems running on i386 CPUs.

The LSB FAQ answers the question "Is the LSB only for Linux systems and applications?" thus:

No. The spec has been written so it can be readily implemented on top of any UNIX-like operating system, natively or as a compatibility layer. There is also no fundamental reason why it cannot be implemented on other operating systems, although it is likely to be much more work. Note that this philosophy may be one of the reasons why a seemingly "obvious" Linux feature is not part of the specification if it raises needless barriers to implementing the LSB on non-Linux systems.

Unix paths by Too+Much+Noise · 2004-06-05 08:25 · Score: 2, Informative · on GoboLinux Compile -- A Scalable Portage?

a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead

For all those thinking "what a nice idea":

afaik LSB requires FHS which, in turn, requires the standard directory structure. Does this mean we should throw the whole LSB out now?

And no, OSX is not LSB compliant - go figure.

Experiences from Gaim by samrolken · 2004-04-07 13:11 · Score: 3, Informative · on Building Gimp 2.0 on Windows XP?

I've built Gaim for Windows before, and I think it would be quite similar to building The Gimp 2.0 since they both use a lot of the same software...

The basic idea is to install cygwin, and use make and python and perl and all that other stuff the build process needs, but replace the compilers and libraries in your path with the ones from mingw.

See here for more info:

Windows Development - gaim

When installing or compiling UNIX apps that have been ported to Windows, especially ones using GTK+, all kinds of crazy things end up happening with confused DLLs. Sometimes Gaim tries to use ActiveState's Perl and that breaks something, or tries to use some of Cygwin's libraries. What we need is something like the LSB that governs how UNIX-compatible environments (Cygwin and MinGW mainly) should work on Windows. That would be a big help to folks like me who must use Windows (No, trolls. I can't use Linux. I have reasons. Go away.) but want to have appilcations and environments that are UNIXey.

Re:embracing open source? by Gleef · 2004-04-05 07:45 · Score: 1 · on Microsoft WiX Code Released to SourceForge.Net

zegebbers asks:
If [an installer is] no big deal, then why is it nearly impossible for me to get a standard way for installing softwre[sic] on linux?

It's not, just create an LSB-compliant RPM file. Full specifications can be found at the LinuxBase.org website. Most recent distros can handle LSB-compliant RPM files with no hassle (even "old and non-compliant" Debian Stable/Woody can handle over 99% of them if you install the lsb package).

IMHO, it's perfectly legitimate to say "Requires LSB compliant Linux distro" in this day and age. Your once legitimate gripe goes in the "old news, fixed already" bin. Now, if you want native installs for multiple distros, you might elect to put some extra work into it, but a single LSB package should be good enough for most things.

Re:embracing open source? by ndogg · 2004-04-05 04:57 · Score: 1 · on Microsoft WiX Code Released to SourceForge.Net

There is a standard. It's a matter of actually using the standard that is the problem.

Re:Apple's Lifeblood by spacehunt · 2004-03-19 16:19 · Score: 1 · on Why iPod Can't Save Apple

You might want to have a look at the Linux Standard Base for a widely supported binary executable format standard.

Re:Fantastic News by iantri · 2004-03-19 04:00 · Score: 1 · on YaST to Become Open Source

This is, of course, what the LSB and FHS are for.

I can't say I particularly agree with some of their design decisions, but they are trying to create a Linux standard.

Afaik, SuSE is LSB-compliant. (The /etc hierarchy certainly looks like it)

Red Hat/Fedora implements some if it, and Mandrake has it as an option (see the "LSB" option in the installer).

Re:My own experience with SuSE.. by jmt(tm) · 2004-03-18 06:46 · Score: 2, Interesting · on Novell Announces SUSE Linux 9.1

I'm using SUSE as my primary distro for a couple of years now, and I think SUSE has evolved greatly, supporting Linux standardization efforts widely.

While they are definately producing one of the most polished distro's available, it deviates from most linux distributions somewhat dramatically

There will alway be differences between different distributions, but I think that LSB and FHS compliance is the key. SUSE 9.0 is e.g. certified to comply with LSB Runtime Environment for IA32 Version 1.3

I still don't know how exactly the init system works.

The init system is designed according to the LSB specifications. I personally find it very easy to use.

I also found that you HAD to do things SuSE's way ... you couldn't do it yourself because YaST would stomp all over your changes.

Why this partly was true for older versions of SUSE, the sitaution is much better now (or my knowledge on how to do things improved:-). Of course, there are things like when you have a configured X and then start the X config programms, you'll get an altered XF86Config. But I find that's hardly surprising.

I happily alter config files by hand all the time and I experience no problems using YaST on other occasions.

(again, you can't just update say, package X from a source tarball because SuSE will throw a fit).

You know what package management is all about, right? How can you expect the system to know about your nicely compiled update if you don't tell it? You can't get it both, the comfort of managed software installs and the freedom of source upgrades without spending some work on it.

I frequently install software from source, either newer versions than the ones from SUSE or stuff not supplied by them. The key is to build packages out of them. It's really not that difficult (it gets difficult when you want to build a whole consistent distro, that's why I happily pay for SUSE's boxes - they do all the dirty work).

It's probably not bad for novice and intermediate computer users; I'd reccomend that experienced users who want a pretty desktop with little hassle use Mandrake.

I'd recommend SUSE for both :-) I think SUSE is a very nice distribution usable both for the newbie and more experienced users. Heck, I also like Debian and SouceMage, but in my experience, SUSE delivers a good allround solution. That's why it runs on my laptop, my desktop, and some servers around here. The cluster, otoh, belongs to SourceMage :-) .

So, yes, my experiences do differ. But that's OK, isn't it?