SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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).
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.
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.
Last edited by Alien_Hominid; 11-19-2007 at 05:14 PM.
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.
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.
FULL ACK!!!
thats one of the main points why linux isn't making it to the desktop..
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.
...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.
Last edited by Alien_Hominid; 11-20-2007 at 05:47 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
