Why Slackware isn't LSB compliant?
 

Hi guys,

I have looking for a answer in many Linux forums, in discussion lists, in the Slackware Official Site, etc. And unfortunately I did not find anything that would answer my question. So I would like to know why Slackware Linux is not LSB (Linux Standard Base) compliant? Or why LSB did not recognize Slackware Linux, yet?

p.s. I send a mail to info@slackware.com but they did not reply.

regards,
testing.

Well, for one thing, the LSB calls for packages to be installed via RPM, and Slackware has it's own package format.

As to the rest, read http://en.wikipedia.org/wiki/Linux_Standard_Base

Perhaps because Slackware came first??

And---if, as noted above, LSB requires RPM, then I would it say it is flawed. What are all the apt/.deb users supposed to do?

Slight difference on that. LSB doesn't call for packages to be RPM. Rather to be LSB compliant a distribution must be 'able' to use RPM.

Debian has this as an issue as well. It still uses .deb packages* for all it's repositories. But as a nod toward LSB compliance it's capable of handling RPMs via the Alien system (essentially it converts it to a .deb and then tries to fill in the gaps).

Not really a Slackware user, but I recall reading somewhere that it was LSB compliant?

[ * A far better format I think, but I'm really not trying to start a flame war on this one]

According to that wiki I can't think of ever having any issues using rpm2tgz to convert rpm's to slackware tgz package formats. Then just installpkg the resulting tgz file.

At a guess it'd probably be something to do more with the file sys? personally I prefer slacks layout over rh etc.

If you want another good idea of why not very many people who don't have piles of money to throw at the problem really want anything to do with the LSB, just try reading it.

They've basically frozen the ABIs for everything in stone, which is all well and good for them, but as a lovely side effect doesn't allow much wiggle room to fix anything that is later determined to be fatally broken.

Yeah, there's lots of contradictions in the syntax required for many programs. And they don't always agree with the latest POSIX standards either. Most distros have been pushing the last couple of years for better POSIX conformance, but even that makes lot's of people angry as it breaks lots of programs and scripts even though the latest standard is from 2003. Add in differing opinions and conformance levels to FSF, OSS and GNU standards and it makes for a pretty mess -not to mention LFSH...

There are a lot of "standards" and capital character combinations that would help the mankind to have a better future..but I don't really think it's going to work like that. For Windows or OS X it's a must to have some rules on how to create the programs so they'll fit into the environment, but Linux based operating systems are a wider field..I'm not sure if it ever works out having a "standard" that says how things ought to be done. I think things ought to be done so that they work best for what they're made of; why make a program less efficient, simple or something else just to make it "compatible" with some standard?

Not to mention the other questions; why RPM and not DEB or TGZ, why this, why that? Yeah, (ex-Windows-)software companies would love to see a three-character mark that states a product is able to install a program in the form preferred by the software company, but how does it help the products - operating systems in this case? And if we now started turning every app into an RPM (and install it with different package managers and tweaks onto different operating systems), and eventually most of the software were packaged as RPM, and then one day it was found out it's really a lame thing, would it be sensible? And if software was distributed as source code (.tar.gz or something) and RPM, why not distribute it in the other forms also? A whole lot of questions raise up on one matter only, so I don't think I'll go for the rest of the deal..

Slackware works fine, even if it's not stated as "LSB compliant", so what's the problem? Some company can't get money because they're lazy and don't want to package their supercool-and-patented-and-proprietary software into Slackware .tgz?

Another reason why Slack may not be classed as LSB compliant is because it uses BSD style init scripts. Most distros store scripts for their services and startup in /etc/init.d, but I think its /etc/rc.d for Slackware.

Simple answer:

It could easily be, it already is for most of the important bits, but why would you need it to be?

Slackware is a linux distro just like any other - it does some bits differently to the rest, otherwise it'd just be BlueHat or GreenHat - a carbon copy. It doesn't NEED to be LSB-compliant and there is very very little software that demands LSB compliance - and there are none can't be fixed. Plus, as others have pointed out, LSB isn't really a good standard anyway. Slackware gives a nod in it's direction with a symlink or two to comply with the LSB filesystem layout, but it doesn't have that much interest in LSB because, basically, neither does anyone else.

It's probably only the very-expensive, paid-for, closed-source programs that are run in large businesses that actually demand LSB-compliance, but none of them actually need it. And as time goes on, LSB will start to matter less and less.

No. Slackware uses a SysV init, thanks.

http://refspecs.linux-foundation.org...srcinstrm.html

Yes, Slacware uses SysV init, but uses BSD-style init scripts- In the latest versions the initscripts package does install SysV-style init directories since some of the software included with Slackware requires some of those scripts including /etc/init.d/functions. Still the basic functionality and boot-time init scripts are *similar* to BSD init-style in that they do not have separate scripts which are run for each runlevel and most everything is located in /etc/rc.d and not in /etc/init.d.

source: http://www.slackware.com/info/

There you go. Also, I personally don't give a damn if it doesn't comply to the LSB standard in particular ... because I find it rather silly.

The Slackware site says they use BSD style scripts.

wiki says that the LSB has some std. packages that every LSB distro must contain.
but where do i find a list of these packages???

From when did Slackware start to use System V? It's an advantage to use rc.d because System V is more messy and so more dificult to comprehend for manual editing.

Please read gnashley's post, to understand the difference between "BSD style" and "BSD" init scripts. Maybe you should read how the BSD init works - it is fundamentally different from Slackware's init system.

Eric

One good thing about LSB is that it helped to overcome the problem that RPMs for Red Hat wouldn't run on SuSE and vice versa. Just one example what standards or the councils where people meet can be useful. And for server farms it is good to know that at least a minimum standard of compatibility is guaranteed, and that packages fulfilling certain criteria will work. And, BTW, managers like to believe in certification labels, which is probably the main reason why SuSE and Red Hat are so much more popular at ISPs and in large companies than Slackware these days.

While we all know why we prefer Slackware, the reasons are mainly technical in nature. But you can't usually convince the management with technical reasons. You must be either compliant with open standards or backed by a huge company, otherwise they will find it too risky to use your product.

gargamel

The BSD-style init scripts are there because they are simpler and easier to understand and modify. The SystemV init is there because, AFAIK, it has to be (at least for Linux).

My impression always was that Slackware always used BSD style init scripts (everything is in /etc/rc.d, chmod +x/-x lets you enable/disable the script, and one of the scripts is sysvinit which takes care system V style scripts installed by other packages).

Slackware knows the concept of runlevels (like System V) whereas BSD does not use runlevels at all.
Nevertheless, the layout of the /etc/rc.d files is such that you can refer to them as a BSD style set of init scripts with SysV added on top.

Eric

No standards means lots of broken things and constant headaches - more whining users what a crap Linux is. Do you need a proof? Look at Xorg. Almost after each upgrade something is not working, removed (imho, without serious reasons) or broken. I don't have time to read each package changelog to get why it's not working.

Same goes to laptop market. Until Intel introduced CBB (common buildings blocks), you couldn't upgrade laptop parts because everything was non-standard. Even now Nvidia chips are purposefully soldered that you couldn't upgrade your laptop and better buy a new one each time you need more powerful GPU. Exploitation of consumers.

If there were no standards, most hardware will be useless to linux users cause there won't be enough developers (RE also needs lots of time) to write all the drivers for these devices because almost none hardware manufacturers provide native linux drivers. Even now there aren't open source wireless drivers (atheros haven't released their, have they?).

EDIT: I could ask why there is a lack of enthusiasm from manufacturers to write linux drivers. One reason might be because there are no ONE standard.

Thanks for an explanation.

Read more carefully.

...or read http://noobfarm.org/?446 which contains a quote from Patrick Volkerding.

...but there is one kernel (or at least one main tree for people to worry about) and that's the only thing device drivers need to worry about.

FULL ACK!!!

thats one of the main points why linux isn't making it to the desktop..

No, it's just bad logic. Distributions handle the fine details of those sorts of upgrades for users.

Complaining that there's something wrong with Linux because you can't manually upgrade something complex without making an effort to learn something about it is no more sensible than saying Windows will never make it to the desktop because someone mailed you a bunch of DLL files and you couldn't figure out where to copy them to upgrade Internet Explorer.

Good question/answer... so I have another one for you... why did not Slackware become a distro standard? It came first...

And Slackware doesn't support RPM anymore...

Probably because Slackware didn't go corporate like Red Hat. Also, the rpm package management system was very highly regarded back in the day.

Since when kernel guys develop alsa (not all old oss aps work with it)? In addition, proprietary drivers from nvidia and ati also load Xorg provided modules. If there is no consistency there, why it's always ati or nvidia developers fault. I remember that fglrx needed to be hex-edited because xorg version number just changed (what for?) and it simply stopped working (fglrx).

There is one Windows OS, but lots of different Linux distributions, which in reality are same OS. What you have learned in Ubuntu, won't work with Suse and vice versa => no consistency.

Because Pat's too clever for it?


Cheers,
Tink

i really don't see how you can say all distros are the same OS?

can you say gentoo and ubuntu are the same operating system?

one comes on a CD and the other is built on my machine.

just because they can share the same kernel doesnt make them the same OS.

Software is the same between all the distros. (that's why they are called distros). Different distribution of mostly the same packages.

First of all you have to define "OS". Linux is just the kernel and can't do anything by itself. Only in combination with other programs can it actually do anything. You can, in fact, create a system with a single executable 'linuxrc' and boot that as an initrd. Most people would not call that an OS, but the point is where do you darw the line. It's fair to say that the kernel alone is the 'OS', but it's just as fair to say that it is not. All distros do not use the same software, nor do they implement it the same way when they do.
The arguments about whether Slackware is a SysV init system are also semantical. Yes it uses an init daemon called SysV init, but the scripts associated with it are neither like the other distros which are SysV systems, nor is it like the scripts used with BSD. What it is, is the Slackware way of doing things and it's just as valid as any other way.

I agree that industry standards can be a good thing, but I also dislike being locked in to just one thing, so I am glad that there are distros which go their own way. But distros, software authors and software packagers who have no regard for any sort of conformity usually go away quickly.
Strangely, the recent moves *towards* conformity has caused more breakage than doing things the old way. This is true with Slackware and other distros as well. I remember seeing some pretty hot discussion about a year ago when Mandriva suddenly switched to using dash instead of bash. Because dash is completely POSIX-conformant, it broke nearly every script used wth Mandriva. Some months ago(before Slack-12 came out) PatV upgraded to bash-3.2 and then quickly downgraded again for the same reasons -it broke too mayn script-based programs which are written and maintained by third-parties. If you have a look at the SlackBuild for coreutils, you'll see that Pat is still compiling coreutils to conformance with the old (1999) POSIX standards and not the newest (2003) standard.

What's really absurd to me is people who always feel that they have to have the latest cutting-edge applications, nut are mad as hell when some common utility breaks things because of being upgraded -for whatever reason. I was looking not long ago at util-linux-ng package. In this new version the 'mount' program no longer mounts partitions unless you specify the filesystem type. No more 'auto' options in fstab, no more scanning /etc/filesystems for the type.
And how many people will be mad when Slackware finally makes the plunge to full POSIX compliance? For coreutils this mostly affects the programs head, tail and rm.
You know, when we all get to full POSIX-2003 compliance then the simple elegant -:) command rm -rf /* will no longer work! Some folks are gonna have to change their forum signiatures and favorite bit of advice...

Summing up, The strongest and weakest points about the Linux kernel and associated open-source programs used with are one and the same. There is no enforced standards compliance -no 'right way', no 'wrong way'. That leaves each user and developer to make those decisions themselves and everyone is as free to leave as they are to join.

This is why I don't try to teach people about distro-specific mechanisms, and part of the reason I use Slackware to begin with. Once you know how things actually work, what you've learned on one distro does work on other distros (and frequently non-Linux systems like HP/UX and IRIX as well).

as pointed by gnashley (out much more eloquently than I will) the software is not the same. they might start from the same (or similar, depending on patches) source, but when you look at the binaries across different distros they differ significantly.

filesystem structure, filesystem type and user interface are also interwoven into what I would consider an operating system.

If you look at just the surface differences:

one distro may favor XFS, another reiserfs - entirely different interface with the two layers of hardware abstraction below. Also different software to manage said filesystem.

window manager or desktop environment - I don't even think you can compare the 'operating' of fluxbox with KDE. Almost noone expects to pop in a install disc and be left in runlevel 3 anymore. (search this forum for 'installed ok but I just get this blinking cursor')

I think to the end user many 'distros' could easily be considered an independent 'operating system'.


the different Linux distributions do share a kernel in common*, and some core packages, but they are more often _very_ different than similar - and tailored to suit each distro's specific needs.

*also, its worth mentioning that the 'same' kernel has about 10^6 options and can be built quite differently across distributions. Looking only at stock kernels you can find some distros force SMP and others dont. Some ship with kernels en/disabling acpi or apm, or some with/without MSI, DMA the list goes on..

these are fundamentally different approaches to hardware level interactions. That makes an argument that unless the shipped kernels are configured the same way - they're different.

There used to be a big push by some people to talk about GNU/Linux rather than just Linux, because linux itself is not really an OS, but GNU/Linux is. I haven't heard this for a while, but it is a valid point. When people say "Linux", I think they are usually referring to the kernel + the basic set of (GNU) tools and utilities which allow you to actually do things.

I also strongly support evilDagmar's point. While there are many different ways of doing things, if you avoid distro-specific tools and learn how things really work, you can find your way around most Linux systems, and even other unix-style systems. As an example, with no experience on a Mac, I was able to install and configure apache, perl, php, mysql, and a web application I wrote using these technologies on a Mac OS X server in a couple of hours (using the CLI). If I only knew the gui-based tools of this or that distro, I would not have been able to do so so easily. That's why they say "if you learn Slack, you learn linux". I don't think people realize that most gui tools in linux are basically just interfaces to command-line programs which, by and large, are common to all linux systems.

So what if one distro favors one filesystem and one favors another. If you want you can use any filesystem on any linux machine. And the (CLI) tools for managing said filesystems are the same.

KDE, Gnome, XFCE, etc. are desktop environments, not operating systems. Microsoft has tried to get everyone to think that all of this is part of the OS (along with web browsers, media players, etc.) It is not true. Also, just like the filesystem point, you should be able to install an use, eg. XFCE, on any linux system regardless of whether the distro itself prefers or uses it.

Brian

please re-read the forum title ' slackware ' I think most people in here realize exactly this. :D

its not about if you can work the OS from a CLI interface as much as if you can work it from the _intended_ end-user interface.

Most who have used slack for long could manage the other distros out there, but that doesn't inherently make them the same OS. Thats like saying because I learned some concepts of CLI from DOS and then jumped into linux, DOS and linux are the same. I have learned things about windows from linux - does that mean they are the same? ifconfig -a ~= ipconfig /all

You may not consider the window manager part of the operating system, but I'd argue that depends entirely on the intent of the developer and client.

Most computers spend their lives dishing up pretty graphics for us to look at I'd say the window manager is most certainly a central part of the operating system. Would you say the cellphone in my pocket and my dell core duo are running the same OS, both have linux, gtk (maybe qt on the cell phone, can't be sure) ?

Not all the same programs are used for all file systems either, hence the reiserfsprogs and xfsprogs etc..

maybe I'm just being to pragmatic here, and I do think I understand the 'all distros= one OS' camp point of view, but to me the differences in how hardware is handled and how the intended end user interacts with a system are unambiguous.

Why? If I can get the job done with the CLI, what does it matter if I learn each gui interface for each distro? And the fact that I CAN get the job done on any distro with the same CLI commands to me means that it is the same OS with different window-dressing.
But that's the point. I can use ifconfig on any linux system, but I can't use it on Windows, because Linux and Windows are different OS's.

So where do you draw the line, or are you saying that all programs installed on the computer become part of the OS just because the developer says so? Not everything on your computer is part of the OS.
But you should be able to install reiserfsprogs on any linux distro, where you couldn't on Windows, because GNU/Linux is one operating system and Windows is another.
I fully agree that differences in how hardware is handled (at a low level) can make OS's very different. But the hardware interaction is the primary job of the kernel and GNU tools, which are common across distros.

I emphatically disagree that differences in how the end user interacts with the system makes for a different OS. By your definition, if I use Slackware with Gnome and you use Slackware with XFCE we are both using different OS's.

Noone is saying that all distros are the same. I'm just saying that under the hood the core OS is the same. If you define OS as everything that is included with the distro (the way MS wants you to think), then you are correct. If you define OS as the kernel and the basic set of tools which allow you to interact with your computer (and build programs which do) then you are wrong. I don't think you are being pragmatic at all. What I consider pragmatic is learning the core Linux system so that you don't have to be bothered by the superficial differences between distros.


Brian

Maybe some definitions are required here:

OS= Operating System. The core set of instructions for the hardware to operate.

CLI= Command Line Interface. Text based operator interface to the OS.

GUI= Graphical User Interface. A graphical (pretty picture) way for the operator to interface with the OS

Distro= Distribution of GNU/Linux, using a common kernel (the Linux kernel) and common core utilities, with possibly different file structures, non-core utilities, interfaces, etc.

By just these definitions, Gnu/Linux is the OS. Windows is the OS. DOS is the OS. OS X is the OS. The previous argument about the different kernel options making a different OS are bunk. Those are OPTIONS. I compile my own kernel. That alone does not make it a different OS. It's still Gnu/Linux, but optimized for what I and my hardware needs. By the same token, using Xfce does NOT make my Slackware a different OS than if I use KDE or Gnome. The CORE SYSTEM (kernel, GNU stuff) is the same as most other GNU/Linux OS's. The kernel for Windows Vista, for instance, is MUCH different then the Linux kernel, thus a different OS. As is OS X, and DOS.

But all of this is getting off-topic. How about the original question? Why Slackware isn't LSB compliant?

My short answer is: Why should it be? I make it as compliant as I need.

I very much agree.

I'll add something to the original LSB question: now that I think I've never ever before bumped into that three-letter combination, 'LSB', anywhere. I haven't seen it on the web on my daily surfings, haven't seen it in the installer, haven't seen it in the various Linux operating system packages, haven't seen it at any software packages at the store (physical or web-), I just have never known it existed. So is it important? Needed? Lacking it, or should I say using distributions that don't have it stamped on them, has not made my life too difficult yet -- so is it really worth declaring, after all?

And another thing: why don't all those "Microsoft Certified" (and alike) products function perfectly, without any problems or extra time consumed in making them work the way they should, if they're so certified, branded and tested? Come on, that's exactly the same thing - a bunch of letters that should tell the customer "this product works on other products that have the same name in them". Yet I still get driver problems, crashes and all kinds of situations I never expected even if I do put a "Microsoft Certified" program or piece of hardware into a computer running Microsoft Windows. So it doesn't automatically mean one's soul is saved - does this sound like Slackware would need 'LSB compliant' marking?

1) Imho, what defines and differentiates a distro and an OS is binary compatibility. If you take an ELF file from one distro to the other, it may work (depending on the libs). If you take this file from one OS to another, it of course won't work.
2) LSB compliance is required by some proprietary tools (e.g. vmware-tools, if I'm not mistaken).

Yes, that would be by RMS, and if he's around and you say 'Linux' instead of 'GNU/Linux', I've heard he will slap you hard upside the head :D

Quite right, too. Without all the GNU tools there would not be any "Linux" distros. What would have happened to the kernel if that "marriage" had not taken place?

The problem is as noted very many times that 'GNU/Linux' is a real mouthful ... how exactly is it pronounced gee-en-u ? guh-nu ? gee-nee-u ? whichever way it is, it takes long to say and has ambiguous and difficult pronunciation and like many words in the same category, they do not catch on with the public. Thus I say 'Linux' is a good enough alias for 'GNU/Linux' as long as people know that 'Linux' in the most general usage includes 'GNU'.

As to what would have happened to GNU, well as it says on wiki, at about that time RMS made the sad mistake (he regrets it now) of choosing to develop the Hurd kernel from the Mach kernel instead of the BSD "4.4-Lite" kernel (there were also a 'lack of cooperation from BSD programmers). To this day Hurd is not finished ... and it won't be anytime soon :)

I meant what would have happened to the Linux kernel without the GNU tools.

oops, I misread that, it was actually quite clear in your other post.

Actually, I'm not sure what would have happened. Some say the Linux kernel would have become proprietary. I doubt this, because Linus T. said on many occasions that he wanted the kernel to be open-source and freely available to all. I think what would have happened would be there would be GNU and two kernel to choose from: Hurd and Linux. I think Debian already offers this option ... for those adventurous enough to try the Hurd kernel :)

But then, it wouldn't be "Linux" anymore, would it?

There won't be neither decent GNU/Hurd nor Something/Linux. They probably would be more like hobby OSes (smth similar to plan 9 - good OS without much success). Lots of GNU/Linux developers would probably go to BSD or join windows cracking force (that's just my opinion).

I guess we can no more predict the past that might have happened than we can predict the future that might happen :)