LinuxQuestions.org - Why Slackware isn't LSB compliant?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Why Slackware isn't LSB compliant? (https://www.linuxquestions.org/questions/slackware-14/why-slackware-isnt-lsb-compliant-600818/)

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.

Quote:

Originally Posted by reddazz (Post 2964379)

The Slackware site says they use BSD style scripts.

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

Quote:

Originally Posted by ledow (Post 2964258)

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.

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).

Quote:

Originally Posted by Alien_Hominid (Post 2964612)

My impression always was that Slackware always used BSD style init scripts

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

Quote:

Originally Posted by b0uncer (Post 2964174)

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?

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.

Quote:

Originally Posted by Alien Bob (Post 2964630)

Thanks for an explanation.

Quote:

Originally Posted by reddazz (Post 2964379)

The Slackware site says they use BSD style scripts.

Read more carefully.

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

Quote:

Originally Posted by Alien_Hominid (Post 2964637)

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.

...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.

Quote:

Originally Posted by Alien_Hominid (Post 2964637)

FULL ACK!!!

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

Quote:

Originally Posted by e.v.o (Post 2965216)

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.

Quote:

Originally Posted by pixellany

Perhaps because Slackware came first??

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.

Quote:

Originally Posted by evilDagmar (Post 2964907)

...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.

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.