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.

1 members found this post helpful.

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.

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

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