Latest LQ Deal: Linux Power User Bundle
Go Back > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Slackware This Forum is for the discussion of Slackware Linux.


  Search this Thread
Old 05-18-2013, 01:18 PM   #16
Registered: Nov 2001
Location: US
Distribution: Slackware 14.2
Posts: 342

Rep: Reputation: 83

Is it possible for mods to ban links to certain blog authors? I don't see the purpose of posting any links/articles from this particular author considering her well known (and constantly voiced) opinion of Slackware.
2 members found this post helpful.
Old 05-18-2013, 01:18 PM   #17
MLED Founder
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, MLED, MLES, CentOS
Posts: 3,278

Original Poster
Rep: Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816Reputation: 1816
Originally Posted by kabamaru View Post
@kikinovak: You definitely have a thing for her. Just admit it already.
To get a vague idea.
2 members found this post helpful.
Old 05-18-2013, 01:30 PM   #18
Senior Member
Registered: Feb 2009
Posts: 1,299

Rep: Reputation: 547Reputation: 547Reputation: 547Reputation: 547Reputation: 547Reputation: 547
so the LSB is not Slackware-compliant.
that means obviously that the LSB needs to be reworked
8 members found this post helpful.
Old 05-18-2013, 01:33 PM   #19
LQ Guru
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 5,058

Rep: Reputation: 1031Reputation: 1031Reputation: 1031Reputation: 1031Reputation: 1031Reputation: 1031Reputation: 1031Reputation: 1031
Originally Posted by kikinovak View Post
"Finally, I'm sure fans of Debian and Slackware packaging will disagree with me, but keeping to standards, specifically the LSB, also goes a long way to insure application compatibility. I think it's vital that all enterprise distros follow standards."
I don't agree that Slackware needs to follow standards set by a big corporation. I'm not as rabidly opposed to her writing as some of you are. I don't find her writing compelling or interesting.
Old 05-18-2013, 01:45 PM   #20
Registered: Mar 2011
Distribution: Slackware 64 -current,
Posts: 550

Rep: Reputation: 194Reputation: 194
Originally Posted by JWJones View Post
Her disclaimer aside, that was a Red Hat suck-up piece. Whatever.
I think you nailed it there. Redhat isnt as bad as microsoft in pushing their way as the standard, but i think they would be if they could be.
1 members found this post helpful.
Old 05-18-2013, 02:20 PM   #21
Senior Member
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543Reputation: 543
Stability is indeed important to enterprise users and admins. Important to non enterprise users and admins too.

Because the requirements of LSB include SysV init scripts and RPM packaging, I always thought LSB should be renamed to RSB: Red Hat Standards Base. I'm not trying to be funny or cute, just straightforward.

LSB is an illusion. Something designed to get people to ask the wrong questions so nobody has to worry about the right answers. Simple sleight-of-hand to fool less knowledgeable people. Red Hat is first and foremost a business and the people working under that legal fiction are focused on business. That implies intensive marketing. Marketing, by nature in the modern world, involves deception and sleight-of-hand. People behind LSB are acting like peacocks to show the colors of their feathers during courtship.

Dietrich Schmitz's claim that Red Hat's adherence to the Linux Standards Base (LSB) guarantees stability and reduces costs in the enterprise is horrible logic. LSB provides no provisions for stability and reducing costs. No standard, real or illusionary, provides such provisions. Standards provide common mechanisms and methods.

That Red Hat Enterprise is stable is a testament to vigorous quality control and has nothing to do with LSB.

If a primary criterion of enterprise usage is LSB, then Red Hat will always satisfy those requirements. Yet if one realizes that LSB is a proverbial red herring, then that criterion disappears like the dew on a hot sunny morning.

I won't deny that Red Hat influences enterprise usage of free/libre software. I don't know whether that is "good" or "bad." Just is. Decisions made in the enterprise tend to influence other areas of usage. The trickle-down effect. The solution then is for people to become better informed not to be fooled by marketing sleight-of-hand.

Regarding Red Hat stability, I believe Caitlyn is correct. Ignoring the bleeding edge, half insane Fedora, I believe the standard Red Hat Enterprise release is indeed stable. Other than security patches I believe most software in the enterprise version is not changed willy-nilly every month or even every year. Eventually that means using software that is several years old, but the Debian folks have done well with a similar model. Bleeding edge is not the name of the game with Red Hat Enterprise (or Debian).

The allegation Caitlyn made against SUSE Enterprise does not hold against Slackware (and Caitlyn made no such connection or allegation against Slackware). The only changes made in an official Slackware release are security patches. If viewed only from that limited perspective, Slackware qualifies as stable.

Is stability important in Slackware? (Caitlyn and Dietrich never argued as much.) Pat indicated that stability is important based upon his public request for opinions about which kernel version to use for the next official release. The long standing practice of issuing only security patches and not sneaking in general package updates further testifies to a goal toward stability.

One thing I detest with the free/libre software model is updating software for the sake of updating. Yesterday I was smacked by this madness with Firefox. This insane attitude is the equivalent of shooting oneself in the foot. In that respect, the term stability means a lot to all users. Design models should not change simply for the sake of change. (I'm still pissed about that change in Firefox, hence my long venting in this response. )

Are various tools such as PAM, SELinux or AppArmor important? I don't know. I'm not an enterprise admin and I am not well versed in that area. Yet I've used computers for more than three decades. A simple question is why are those tools considered important? What value do they add that the foundational design of 'nix systems do not provide? What criteria are used to establish that perceived value?

Another question is how many layers of security are deemed necessary? Like many areas of life, security concerns must face a point of diminishing returns. How many locks do I install on my house doors before I realize they are useless against the simple act of breaking a window and climbing through?

Is Slackware LSB compliant? Does any informed user really care? Especially since informed users realize that LSB is designed to benefit Red Hat and nobody else?

Slackware is different. Most users prefer not to have package dependency resolution, prefer the simpler packaging method, prefer BSD style init scripts. As long as that continues, Slackware will always be an "outsider" with respect to LSB and Red Hat. Yet by the same definitions and presumptions used in LSB, Debian also will always be an outsider.

That pretty much has always been the story in Linux based systems. That is, there are only three foundational operating systems: Slackware, Debian, and Red Hat. Almost everything else is a derivative. As long as those three foundations continue to be different in fundamental design choices, there never will be any adoption of LSB as currently defined.

Is that "good" or "bad"? I don't know and I don't care. In an enterprise environment I understand and appreciate the desire for some standards. The critical point is which standards? Analogies always break at some point, but this is somewhat like metric versus other measurement systems. There is no "right" or "wrong" system. There is only the criterion of which system works for certain people in certain applications.

LSB works for Red Hat because LSB was written primarily by Red Hat people. Red Hat will always be LSB compliant, which from a marketing perspective tends to sound impressive when selling systems to less knowledgeable customers. Yet Slackware and Debian providers could use similar tactics.

Standards have a role in human life but only when those definitions satisfy the needs and wants of many people. LSB does not qualify as a standard because only Red Hat people find the definitions palatable. Remember that the people working under the legal fiction of Canonical, another free/libre software business, long ago pissed in the Red Hat garden and are doing quit well without the market-speak otherwise known as LSB.

Conversely, the Canonical people shoot themselves in the foot by playing the bleeding edge game and offering ridiculously short life cycles for releases. In that respect Caitlyn's observations are correct.

Caitlyn's comment that LSB packaging requirements go a long way to ensure application compatibility is a proverbial two-edged sword. Compatible for whom? For other Red Hat derivative systems? Yes, packaging in such a manner offers high compatibility. The other edge of the sword blade is a common packaging format will never guarantee full compatibility with non Red Hat systems because of underlying differences in system design. Red Hat folks have strived for several years to change the underlying file system hierarchy. Package compatibility is meaningless to anybody using a system that does not use the same file system hierarchy as Red Hat systems.

Should all enterprise distros follow standards? As LSB is an illusion, then which standards should be followed? Most distro maintainers follow the traditional 'nix file system hierarchy, but the Red Hat folks do not.

From my corner of the world I notice that in the past Red Hat people were content to be Red Hat. Now there are employees working for Red Hat who have embraced an attitude that they should rule the world. They might succeed to some degree but the anarchist nature (anarchy: without rulers) of free/libre software means they never will prevail to the degree they envision. They might dominate certain aspects of free/libre software but they never will rule all.

There is danger with that attitude: revolt. Should they continue their naive insistence of "enforcing" various features and tools, other distro leaders could and might well band together in a revolt that will not reflect well on Red Hat. The great thing about anarchy is bloody revolution is unnecessary. Folks just shrug, move on, and do their own thing. All peacefully. The folks at Red Hat pushing these agendas should learn from Voltaire's Candide: they should tend their own garden and leave others to do likewise.

At one time people were told they could choose any color they wanted for a car as long as they chose black. Those days are long gone. Likewise for operating systems. Hopefully one day the Red Hat people look in the mirror and pause for serious reflection.
6 members found this post helpful.
Old 05-18-2013, 02:50 PM   #22
Registered: Oct 2012
Posts: 67

Rep: Reputation: Disabled
Ok I decided to actually read her article, wow, it is pretty much a Red Hat PR piece, especially since it didn't mention the "enterprise" linux elephant in the room, Oracle, in her comparison.

All her criteria are actually met or better met by Oracle, not to say her criteria are at all good, they are not. Oracle linux is LSB, it works very much like RH and is supported as long as RH, unlike RH you can use it for free without support, you don't have to install a clone and then switch to RH if you need paid support. Also they will support your RH or CentOS installs without having to convert.
Old 05-18-2013, 03:03 PM   #23
Slackware Maintainer
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,168

Rep: Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095Reputation: 3095
The LSB doesn't require that a system use RPM as its usual packaging tool, only that RPM is present so that RPM packages can be installed. Same with the init structure... there's no requirement that all init scripts be of the S... K... variety, only that if a package installs such scripts into the usual directories that they will work (they do).

But in any case, the LSB has been around forever, and yet the promises of loads of LSB compliant commercial software never came to pass. A truly LSB compliant application will have to link to ancient compatibility libraries that are full of bugs, and nobody really wants that, so commercial software for Linux is nearly always targeted to specific distributions. What that means is that it makes much more sense to try to be compatible with binaries designed for Red Hat or Ubuntu than it does to try to comply with a standard that is seldom actually used. Also, to claim LSB compliance you have to pay quite a lot to be certified.

IMHO... nothing to see here. Carry on.
15 members found this post helpful.
Old 05-18-2013, 04:50 PM   #24
Senior Member
Registered: May 2003
Distribution: Slackware, SLAX, OpenSuSE
Posts: 1,716

Rep: Reputation: 175Reputation: 175
Just for clarification: LSB is not a Red Hat only thing. In fact, SuSE was several times the first distro to fully comply with a new LSB release, long before RH did.

The idea behind LSB actually makes sense, and tries to overcome the problem of "fragmentation" of Linux. Look at it from two perspectives:

1. Enterprise user
Large companies want to be able to rely on standards ensuring that software from their preferred vendors run on their IT systems. (Do you share my impression, that the larger the enterprise the more sissies only interested in covering their own ass instead of advancing the company and its employees are managing it?)

2. Software vendor
Companies selling commercial software to large enterprises are not willing to provide binary packages in several dozens of package formats. Even half a dozen seems too much for them. (But they have no problem feeding 12 or more derivatives of some other operating system, claiming that this is a more "homogeneous" market --- which is pure nonsense, but, of course, each fraction of that *other* market allows them to make more money than the whole *nix market, as the customers there are ready to pay for licences, maintenance and support, while *nix users tend to solve problems themselves!)

The idea of LSB is simply to ensure that commercial software packages will run on LSB compliant systems without modification. And it's not just an illusion, as some said. In fact, I well remember the time, when trying to install a RPM package made for Red Hat on SuSE was a gamble. Thanks to LSB this issue was really lifted, and Red Hat packages finally started to run smoothly on SuSE and vice versa.

This doesn't mean, that all LSB requirements are useful, or make sense from a technological point of view. But it definitely makes sense to have such a standard.

Now, if I like LSB, why do I use Slackware, you might ask. Because almost all the software I want to use works well on Slackware, including the few pieces of commercial stuff, I use. Actually, I was able to compile some stuff on Slackware without problems, that wouldn't compile on RPM based distros, although the software was delivered as a Source RPM package.
The only package I never was able to get working on Slackware is KMyMoney2 with HBCI (German online and home-banking standard) support, because I can't build some dependencies (neither on 64 nor 32 bit Slackware). However, they do work on OpenSUSE. But really, this is the only exception, and as long as there are great alternatives, such as Hibiscus (based on Jameica), this is not really a problem for me.

For everything else about LSB and Slackware, see Pat's post above, which is right to the point.

Best regards


Last edited by gargamel; 05-18-2013 at 04:57 PM.
2 members found this post helpful.
Old 05-19-2013, 02:36 AM   #25
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),OpenSuse 13.2 (Laptop & Desktop),, OpenSuse 13.2 on the wifes lappy
Posts: 778

Rep: Reputation: 98
Originally Posted by gargamel View Post

Do you share my impression, that the larger the enterprise the more sissies only interested in covering their own ass instead of advancing the company and its employees.

+1 for that.
Old 05-19-2013, 05:06 AM   #26
Registered: Oct 2011
Distribution: Slackware, Fedora
Posts: 158

Rep: Reputation: Disabled
Personally I dislike the LSB, if linux distros are going to strive for a standard, they should just aim for POSIX or mostly-POSIX compliance (which tbh a lot of linux distros are mostly complient) to make it compatible for the other Unix-like Operating Systems that are around. This makes it easy to port software to it, and makes it easy to translate experiance with, say Solaris, to Linux.
And honestly, for the most part, Linux distributions are compliant. There are a few issues here and there, of course, and the big issue is actually paying to be certified as POSIX compliant if you make the changes.
It HAS been done, however. Unifix Linux is (or was not sure it's still around) completely POSIX.1 compliant and I *think* was even certified as such:

So, IF distributions want to aim for a standard, POSIX is a much more useful, and attainable, goal. the LSB is just BS that only serves to allow RHEL to brag about compliance to a standard that is utterly meaningless.

As far as Slackware goes, I'm not sure exactly how POSIX compliant it is, I know it's very close, but someone more familiar with the specific requirements would have to tell me where (if anywhere) slackware is not compliant, or if it's just a matter of not having a couple thousand dollars laying around to be certified.
Old 05-19-2013, 05:47 AM   #27
Didier Spaier
LQ Addict
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Posts: 7,096

Rep: Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242Reputation: 2242
Originally Posted by Jenni View Post
As far as Slackware goes, I'm not sure exactly how POSIX compliant it is
Just check.

More seriously, Slackware is close enough to POSIX so that I can use the XCU volume as a reference when I write shell scripts, which makes me happy.

Last edited by Didier Spaier; 05-19-2013 at 05:50 AM.
Old 05-20-2013, 04:08 AM   #28
Registered: Dec 2011
Location: Greece
Distribution: Slackware
Posts: 276

Rep: Reputation: 133Reputation: 133
Old 05-20-2013, 05:55 AM   #29
Registered: Apr 2013
Location: France
Distribution: Slackware; Scientific Linux
Posts: 107

Rep: Reputation: Disabled
What is this linuxadvocates web site anyway ? It is the first time I notice it.
For how long has it been in existence ? Who contributes to its funding ?
Maybe in the mid-1990s Linux needed some advocacy since early experiences with Unix on
PCs were rather disappointing (you can see the book of Christian Kaare on Unix for that,
in particular the comparison of a PC-AT running Xenix with a Sun 3) and some Unix experts
were not pleased by some aspects of the early Linux kernels. At the time, someone familiar
with HP-UX or AIX may have thought of Linux as a toy academic operating system, maybe good
to teach the basics of Unix on relatively cheap hardware, but not useful for productive work
given the inferiority of 386/486 Intel processors compared with RISC processors.
Nowadays, Titan, the top supercomputer of ORNL is running some version of Linux and Android,
a derivative of Linux, has a large share of the cell phone and tablet market. The fact that
Linux remains uncommon on desktop has more to do with the fact that many computer users are
stuck with legacy software and legacy hardware that will only work with Windows, and in many
cases cannot even use the MSDOS command line than with a lack of advocacy. On such persons,
Linux advocacy should be about as counterproductive as
GNOME advocacy, Pulseaudio advocacy or systemd advocacy on a Slackware user.
Old 05-20-2013, 06:32 AM   #30
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 866

Rep: Reputation: 264Reputation: 264Reputation: 264
Originally Posted by edorig View Post
What is this linuxadvocates web site anyway ? It is the first time I notice it.
For how long has it been in existence ? Who contributes to its funding ?
From whois :-
Created on: 24-Jan-13
Registrant: Dietrich Schmitz

cola is always entertaining :-
3 members found this post helpful.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] how to make Slack 13.37 LSB 3.2 compliant waddles Slackware 10 10-02-2012 03:01 PM
Why Slackware isn't LSB compliant? testing Slackware 64 12-07-2010 12:05 AM
Which distros are most Linux Standard Base (LSB) compliant? catkin Linux - General 2 08-18-2009 09:44 AM
Building LSB compatible application with LSB SDK - lsbappchk fails gkiagia Programming 0 01-12-2007 06:00 AM
LSB 3.0 released - Slackware compliance? Yalla-One Slackware 1 09-21-2005 08:34 PM

All times are GMT -5. The time now is 10:26 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration