Talk:Slackware

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


ANNOUNCE: Slackware Linux Distribution 1.00[edit]

17 Jul 1993 at 00:16:36

Every so often, someone "corrects" the release date for Slackware. This is rather understandable, seeing as how various websites give various dates. For example:

"The first version was released on July 13th, 1993."
http://polishlinux.org/linux/

"Initial release 16 July 1993"
-- Current infobox on Wikipedia.

"it was released as "Slackware 1.0" on July 16th, 1993.":
http://connie.slackware.com/~alien/tdose2009/t-dose-slackware.tex

"First released on July 16, 1993, Slackware has come a long way..."
http://lwn.net/Articles/91467/

"Slackware 1.0.0 was released 10 years ago today, on July 17th, 1993!"
http://www.linuxquestions.org/questions/slackware-14/slackware-turns-10-years-old-today-73560/

"Slackware, started by Patrick Volkerding in late 1992, and initially released to the world on July 17, 1993"
http://www.slackbook.org/html/introduction-slackware.html

"1993-07-17 [Version] 1.0":
http://www.slackdown.co.uk/history.html

"1993-07-18 Slackware Linux Distribution 1.00"
http://www.informatica.co.cr/linux-distributions/index.html

The above sources mean that we will keep getting people "correcting" the date, but the release date right from Patrick J. Volkerding's mouth, posted on the Slackware website is here:

http://www.slackware.com/announce/1.0.php

Another source of confusion is the second announcement two days later:

http://www.informatica.co.cr/linux-distributions/research/1993/0718.html

http://groups.google.com/group/comp.os.linux.announce/msg/870d1a0ae6b3b504?dmode=source

Our reliable source ( http://www.slackware.com/announce/1.0.php ) gives us a date and time of:

1993-07-16 17:21:20 PST

Now for the interesting question...

If we assume that the above was set to Pacific Standard Time with Daylight Saving on, then the date and time was 17 July 1993 00:21:20 (UTC).

However, it says "PST" not "PDT", which signifies Pacific Standard Time with Daylight Saving off. With that assumption the date and time was 16 July 1993 23:21:20 (UTC).

But wasn't Patrick Volkerding a student at Minnesota State University Moorhead at the time? His sig has a moorhead.msus.edu email address. Minnesota is in the Central Time Zone, not the Pacific Time Zone.

BTW, the slackbook.org site with the July 17 date listed above is the official guide to Slackware. Linux. See http://slackware.com/book/

So, my fellow Slackwaristas, what is the UTC time and date for the announcement? And what date should we list? --Guy Macon (talk) 02:20, 10 August 2012 (UTC)[reply]


WOW! This is a truely sophisticated (and tough) question. Very hard to decide. My modest input:

First step: What's more important, the very truth or a formalistic truth (i.e. official SW sources)? Official sources should prevail: The SW website and the slackbook. All other sources should only overrule official statements if it can be proven, that the official sources are wrong. As I cannot identify a criterion to decide which source is (materially) correct, only the official SW sources should remain relevant - for formal (yet striking) reasons.

Second step: Which official source is "more" official, the slackbook or the website? I would go with the website, because it is most authoritative - the announcement comes straight from the original creator of SW. In the days of SW's inception he must have perfectly known when the project was released. So the announcement in http://www.slackware.com/announce/1.0.php is the key. As it stems from SW's creator and is posted on the official website, it is official twicefold. And it is also most precise. So what more can one expect! Well, a bit more actually, so lets move further.

Third step: BUT a more than minor problem lies - as you already said - in the ambiguity of the two authoritative announcements. They differ in 4 (!) aspects: date, newsgroup (comp.os.linux vs. comp.os.linux.announce), email address (!) and approval (the header of the later announcement has an "approved" entry). Without knowing the technical details of the newsgroup and Volkerding's circumstances I would chose the first announcement, just because it seems to be highly unlikely that Volkerding mixed something up with the announcements. It must have been this way, that he posted another announcement later.

Fourth step: Your reasoning conc. the timezone: I am not familiar with US timezones at all. As far as I know, Pat Volkerding had been at Moorhead univ. at that time, so it should be as you said. I just wonder if the timestamp was given by him or by the newsgroup software. Anyway, I guess that we could settle on this last step as being the decisive one. Only this announcement is relevant. Further analysis should focus on this announcement and clarify the cirumstances.

Germanopratin (talk) 10:54, 22 August 2012 (UTC)[reply]

Here are the original headers from the comp.os.linux post: 

  Path: gmd.de
        !newsserver.jvnc.net
        !howland.reston.ans.net
        !usenet.ins.cwru.edu
        !cleveland.Freenet.Edu
        !bf703
  From: bf703@cleveland.Freenet.Edu (Patrick J. Volkerding)
  Newsgroups: comp.os.linux
  Subject: ANNOUNCE: Slackware Linux 1.00
  Date: 17 Jul 1993 00:16:36 GMT
  Organization: Case Western Reserve University, Cleveland, OH (USA)
  Lines: 76
  Message-ID: <227gd4$jtq@usenet.INS.CWRU.Edu>
  Reply-To: bf703@cleveland.Freenet.Edu (Patrick J. Volkerding)
  NNTP-Posting-Host: hela.ins.cwru.edu

Everything in the above except Path and NNTP-Posting-Host came from Patrick Volkerding's computer. USENET does not change headers except for those two. In particular, USENET is dateless -- the message may arrive at a node days later with the date unchanged from what the poster set it to. Please note that "Patrick Volkerding's computer" may very well have been a remote computer in another time zone he was logged in to.

And here they are as Google Groups displays them: 

  Newsgroups: comp.os.linux
  From: bf703@cleveland.Freenet.Edu (Patrick J. Volkerding)
  Date: 17 Jul 1993 00:16:36 GMT
  Local: Sat, Jul 17 1993 12:16 am
  Subject: ANNOUNCE: Slackware Linux 1.00

Notice that Google Groups converts the date to GMT and tacks on a "local" that converts the GMT to my "local" time. (My computer clock is is set to UTC, so they are the same)

Also note that http://www.slackware.com/announce/1.0.php has been modified to show PST instead of GMT.

Here are the original headers from the comp.os.linux.announce post: 

  Path: gmd.de
        !rrz.uni-koeln.de
        !news.dfn.de!darwin.sura.net
        !math.ohio-state.edu
        !howland.reston.ans.net
        !spool.mu.edu
        !uwm.edu
        !rpi
        !batcomputer
        !bounce-bounce
  From: volkerdi@mhd1.moorhead.msus.edu (Patrick J. Volkerding)
  Newsgroups: comp.os.linux.announce
  Subject: ANNOUNCE: Slackware Linux Distribution 1.00
  Followup-To: comp.os.linux
  Date: 18 Jul 1993 20:13:55 -0400
  Organization: None
  Lines: 80
  Sender: mdw@TC.Cornell.EDU
  Approved: linux-announce@tc.cornell.edu (Matt Welsh)
  Message-ID: <22cp03$be5@theory.TC.Cornell.EDU>
  Reply-To: volkerdi@mhd1.moorhead.msus.edu (Patrick J. Volkerding)
  NNTP-Posting-Host: theory.tc.cornell.edu
  Keywords: Slackware, distribution

And here they are as Google Groups displays them: 

  Newsgroups: comp.os.linux.announce
  Followup-To: comp.os.linux
  From: volkerdi@mhd1.moorhead.msus.edu (Patrick J. Volkerding)
  Date: 18 Jul 1993 20:13:55 -0400
  Local: Mon, Jul 19 1993 12:13 am
  Subject: ANNOUNCE: Slackware Linux Distribution 1.00

Again, Google Groups converts the date to GMT and tacks on a "local" that converts the GMT to my "local" time (also GMT).

The approved and sender headers are simply telling you that comp.os.linux is an unmoderated newsgroup, while comp.os.linux.announce is a moderated newsgroup. Some of the headers may have been modified by the system that did the approving, but almost certainly not the date.

The two email addresses are the two Patrick lists at the bottom of each post.

My conclusion is that Slackware 1.0 was released on 17 Jul 1993 00:16:36 GMT, and the local time for Patrick Volkerding was 16 July, based upon the following:

Time zone claimed in comp.os.linux USENET post: GMT

Time zone where Patrick Volkerding was living: CDT
Central Standard Time (CST) = GMT-6
Central Daylight Time (CDT) = GMT-5

Time zone claimed by http://www.slackware.com/announce/1.0.php :PST
Pacific Standard Time (PST) = GMT-8
Pacific Daylight Time (PDT) = GMT-7
(It appears that whoever posted that got the info from Google Groups but failed to tell GG to show the original headers, thus they got a version "corrected" for their local time zone (Slackware Inc. is in Brentwood, California -- PST/PDT.))

Time zone claimed in comp.os.linux.announce post: -0400
Eastern Standard Time (EST) = GMT-5
Eastern Daylight Time (EDT) = GMT-4

So the only question is whether we use GMT or local time. I say GMT. That's what was in the original announcement. http://www.slackware.com/announce/1.0.php has been modified to show PST instead of GMT, but Google Groups (formerly DejaNews) has the actual unmodified headers, which show GMT.

Conclusion: Slackware 1.0 was released on 17 Jul 1993 at 00:16:36 GMT. --Guy Macon (talk) 19:58, 22 August 2012 (UTC)[reply]

Note: All of the references to PST above appear to be an artifact caused by someone at Slackware cutting and pasting from Google Groups but failing to click on the "show original" link. That gave them times that Google "helpfully" converted to their local time. --Guy Macon (talk) 18:36, 30 August 2012 (UTC)[reply]

I concur with your conclusion: UTC. That seems rather sensible to me. If anybody objects, he has to come up with a stronger argument. Germanopratin (talk) 09:53, 25 August 2012 (UTC)[reply]

As a final note for anyone revisiting this in the future who may wonder why we are using GMT and UTC interchangeably, GMT used to be the world standard for time, but in 1986 we started using UTC (which is identical to GMT for our purposes) as the the world standard for time and GMT as the standard time zone for the Prime Meridian, (Zero Longitude). Back in 1993 there was still a lot of software using GMT, including most USENET newsreaders. --Guy Macon (talk) 12:43, 25 August 2012 (UTC)[reply]

Development contributions[edit]

I noticed this revision: http://en.wikipedia.org/w/index.php?title=Slackware&diff=500916156&oldid=499501214 . I want to remark that the Slackware ChangeLog.txt will usually pay attribution to contributions from non-coreteam members. But the core team members themselves (like Robby Workman, Stuart Winter, Eric Jan Tromp, myself etc) are usually only mentioned nowadays in case of large updates (KDE, XFCE, X.Org) or when we thought of something smart. We use a private communications channel to discuss the development of Slackware around the clock, so basically everybody in the team contributes, even if they are not explicitly mentioned in the ChangeLog.txt.

Eric Hameleers Sat Jul 28 21:07:21 UTC 2012 —Preceding undated comment added 21:10, 28 July 2012 (UTC)[reply]

Thanks for clarifications from the very inside of Slackware. This is a rather hairy subject. Maybe it makes no sense at all to sort of rank (or even find out about) the input of SW contributors. As you clarified, it is hardly possible to do so from the outside. And even if it were possible from the inside: It would remain delicate for many reasons...

After all, it's not important who contributes the most, but it remains relevant to determine who is really part of core. Being informal is part of the SW culture, which is a sympathetic SW "feature" anyway. So trying to find a SW "core team" is quite "non-slackish", yet it matters for this article.

I guess we ought to change the section then - taking your information into account. Can you tell when that Change.log policy changed (pun not intended)? Germanopratin (talk) 16:37, 25 August 2012 (UTC)[reply]

The more I think about it, the more I like the idea of omitting the list of names. Is someone who does some work that is only part of the Slackware distribution more important than someone who does an equal amount of work that becomes part of many distributions? Let Slackware Inc. give credit on their web page if they want to, and we can link to that if we feel a need to give credit. --Guy Macon (talk) 17:55, 25 August 2012 (UTC)[reply]
I think the list of names is important, otherwise this would appear to simply be the efforts of Patrick Volkerding 'and some other guys who contribute occasionally.' The names are all referenced and Slackware's version of "giving credit on their web page" is including them in the changelog. Centerone (talk) 20:36, 25 August 2012 (UTC)[reply]
This is such a tough topic with many facets. First of all, it really is crucial to Slackware that it is not a one-man show anymore. This means that we can hope that there will be continuity in SW. Everybody remembers the days when Pat Volkerding had been seriously sick - this caused heavy (rational) concern wether Slackware itself would cease to exist. Knowing that there is a core team around him, means a lot for the future of Slackware. It's far more than simply honoring personal contributions.
For that same reason you cannot put a Slackware contributor on the same level as a "general" contributor. Yes, it's true that a kernel developper is a Slackware developper as well, albeit on an indirect level. Nevertheless, as for the distro proper it only counts who handles the distro itself. If Slackware were only maintained by Pat Volkerding and he decided to drop Slackware, than Slackware stood some chance to simply perish. With the core team this case would be different: The distro would change in style, for sure, but it would stay active. So, it is important and publicly relevant, to know about the size and impact of the core team. Is it 5 guys or just 2? Are they all equally active and important or not? These questions matter, purely for pragmatic reasons.
Well, I understand that there is no official documentation about the core team - apart from Eric Hameleer's former presentation. Remember that the core team itself came up with that notion of a core team :-) But as they operate on an informal and personal level, they will not go and show statistics or assign positions - that would be highly "unslackish". After all, everybody feels that it still is Volkerding's project. So, there's no chance that the core team or PV himself will help us to formalize or draw statists. Maybe we should keep the names but desist from evaluating the importance or number of contributions of the persons involved.
Germanopratin (talk) 07:34, 26 August 2012 (UTC)[reply]
After some thinking and re-thinking:
Ok, you are right, Guy Macon. Although I myself included the section with the names, I have to admit, that it makes no sense to list the names, if you can't give substantial evidence. Maybe some of them are core, maybe some are not. It's simply not possible to decide from the outside. And the insiders will not decide. So maybe there's no sufficiently strong basis to list certain names. Let's drop them. After all, it is only important to know that there ARE core members, but it is bold (and arrogant) for outsiders to decide about who is in core and who is not.
Germanopratin (talk) 08:01, 26 August 2012 (UTC)[reply]
Ok, I changed it. I kept Eric Hameleer's article, in order to keep some reference. I hope this is OK. I am not satified with the section, maybe anybody has some ideas how to amend it.
Germanopratin (talk) 08:17, 26 August 2012 (UTC)[reply]
How are frequent mentions in the release notes/changelog not substantial evidence?? Centerone (talk) 21:01, 26 August 2012 (UTC)[reply]
There is no evidence that being mentioned in the release notes/changelog has any correlation with contributions or importance to the project, and good reason to suspect that no such correlation exists. --Guy Macon (talk) 22:04, 26 August 2012 (UTC)[reply]
To be honest: I really would like to have the names in the article. The team is essential to Slackware. And it's interesting to get to know about the development process. But it's simply not possible to infer from the announcements whether a person is considered a team member or not. The statement from Eric Hameleers introduced further doubt into these assumptions. So I cannot see how to draw a picture that is not only colorful but also acurate.
Germanopratin (talk) 12:57, 29 August 2012 (UTC)[reply]
Perhaps we can have a list-of-recent-contributors rather than a list-of-core-team-members. Certainly the recent release notes spelled out very specifically what each contributor was responsible for. http://www.slackware.com/releasenotes/13.37.php Centerone (talk) 20:58, 29 August 2012 (UTC)[reply]
The problem is that the release notes do not claim to be a complete list of recent contributors, and there appears to be no good reason to list the recent contributors and not the core contributors. --Guy Macon (talk) 18:36, 30 August 2012 (UTC)[reply]

Screenshot updated to Slackware 14.0[edit]

New screenshot for Slackware 14.0. I thought it would be nice to see some Slack-specific tool, so I included pkgtool. --Philip Lacroix (talk) 10:39, 24 May 2013 (UTC)[reply]

Very nice! That really improves the article. --Guy Macon (talk) 18:32, 24 May 2013 (UTC)[reply]
Thanks! --Philip Lacroix (talk) 08:30, 27 May 2013 (UTC)[reply]
I like it, too. The nice things is that the screenshot shows a modern desktop GUI and a console windows with a command line programm. This is a visual symbol of Slackware's typical mixed approach: old school core in a modern frame :-) -- Germanopratin (talk) —Preceding undated comment added 13:11, 6 June 2013 (UTC)[reply]


Source model[edit]

The source model is described as "Free and open source", which is incorrect. Here is the list of software packages in Slackware 14.0 which are non-free. In particular, the kernel distributed with Slackware contains firmware blobs which are neither free nor open source. I propose we change the source model to "Mostly free and open source, with some non-free components". melikamp (talk) 21:38, 26 July 2013 (UTC)[reply]

I moved this section up because the section below eats up the next section's title. melikamp (talk) 21:38, 26 July 2013 (UTC)[reply]

There are four basic ways a distribution can handle non-FOSS components. They are:
[1] 100% FOSS, no non-FOSS components made available by the distribution.
[2] 100% FOSS, adding non-FOSS is made easy (may require a recompile).
[3] Some non-FOSS, stripping non-FOSS out is made easy (may require a recompile).
[4] Some non-FOSS, no obvious way to create a 100% FOSS version.
Slackware is [3].
Richard Stallman will tell you that only [1] is real FOSS. Pretty much everyone agrees that [4] needs to be described as non-FOSS or perhaps a mixture of FOSS and non-FOSS (but then again, that describes Microsoft Windows; the TPC/IP code in Windows is BSD-based...)
To my way of thinking, the difference between [2] and [3] is trivial, and I think Slackware was wise to decide on [3]. Anyone who cares about FOSS vs. non-FOSS is likely to have no problem getting the list of non-FOSS components at freeslack.net and purging them -- and in fact are unlikely to trust code that someone else compiled -- but the vast majority of users will be fine with the default OS including some non-FOSS components.
From a Wikipedia standpoint, if properly referenced all of this would be a fine addition to our Free and open-source software page , but I really don't see a point in differentiating between [2] and [3] in the individual OS pages. As I said, the difference is trivial. Some OS's (Android and GNU Hurd spring to mind) are notable for being free or not free, but in general this should be addressed on the Free and open-source software page. You will find many sources talking about mixing in non-FOSS software, but those sources are unlikely to point at Slackware as an example. --Guy Macon (talk) 02:15, 27 July 2013 (UTC)[reply]
I don't understand why you regard the difference between [2] and [3] as trivial. A good example of [2] is Debian: the default install image contains no non-free software, and no suggestions to install non-free software. Slackware, on the other hand, is being shipped with non-free components, and has no option to remove them. Most of the wireless firmware it ships is closed source, so it is likely to include spyware by now, which makes it a highly non-trivial distinction for any user conscious of either security or privacy. (The distinction between firmware and the rest of the kernel is moot: either code runs on your CPU, even it may not be the main one, and has direct access to your RAM. Wireless firmware, obviously, is also capable of reporting to the mothership without ever leaving the wireless card.) You seem to claim it is trivial to deblob [3], but this is actually not true for anyone but the folks who spent years tweaking OSes: computer scientists, programmers, sysadmins, and the top tier power users. For the vast majority of users, deblobbing is an impossible task, and for their sake Wikipedia should call things as they are. melikamp (talk) 12:46, 5 August 2013 (UTC)[reply]
I am not sure why you believe that Slackware has no option to remove non-free components. The link you yourself provided ( http://freeslack.net/ ) clearly says "the purging procedure is relatively straightforward. Simply remove offending packages with removepkg, configure, compile, and install a linux-libre kernel, and finally remove the stock kernel packages (kernel, modules, firmware)." Anyone who cannot do that is unlikely to be happy with Slackware anyway, because that's the standard way of updating Slackware.[1] As the saying goes, Slackware is user-friendly. It's just picky about who its friends are.
I am also not sure why you think that the default install image for Debian containing no non-free software is particularly significant or that Debian makes no suggestions to install non-free software. As the FSF says, [2]
"Debian also provides a repository of nonfree software. According to the project, this software is “not part of the Debian system,” but the repository is hosted on many of the project's main servers, and people can readily learn about these nonfree packages by browsing Debian's online package database. There is also a “contrib” repository; its packages are free, but some of them exist to load separately distributed proprietary programs. This too is not thoroughly separated from the main Debian distribution. Previous releases of Debian included nonfree blobs with Linux, the kernel. With the release of Debian 6.0 (“squeeze”) in February 2011, these blobs have been moved out of the main distribution to separate packages in the nonfree repository. However, the problem partly remains: the installer in some cases recommends these nonfree firmware files for the peripherals on the machine."
The firmware discussion is a good example of something best addressed at a higher level than the Slackware distribution article. Besides, firmware is just the tip of the iceberg: See [3], [4], [5], and [6]. Again, this is all well worth including in Wikipedia, but not here. --Guy Macon (talk) 15:19, 5 August 2013 (UTC)[reply]
I sabotaged myself by the previous reply, so let me try again. Nothing in this thread so far contradicts a simple fact: Slackware 14.0 in all of its forms, as distributed on slackware.com, contains non-free software. Slackware itself offers no way, tool, or option to either install a fully free OS or make it free post-install. (Not that an option like that would make much of a difference.) The fact that one can deblob Slackware is irrelevant, since this page is about Slackware as released by PV and team. Comparison with other distributions is also irrelevant: either Slackware contains non-free packages or it doesn't. melikamp (talk) 16:40, 7 August 2013 (UTC)[reply]
This is not a trivial issue. Normally I share most of Guy Macon's views, but in this case I see some validity in Melikamp's suggestions. Whether [2] or [3] are nearly identical is totally subjective, depending on a guys's technical skills and on his willingness to change a system. And (!) depending on knowing the real facts about the FOSS "level".
Consider a guy who is about to switch to Linux and has to decide which distro to choose. On one hand, it is true that someone who is not technically skilled and not willing to put some effort into his system, will not go for Slackware in the first place. On the other hand, it might give a "distro chooser" a better factual basis for a preliminary decision if the FOSS statement were precise. Germanopratin (talk) 08:23, 11 August 2013 (UTC)[reply]

Consider the following sequence of talk page comments:

Melikamp: "Here is the list of software packages in Slackware 14.0 which are non-free." ... "I propose we change the source model to 'Mostly free and open source, with some non-free components'."

Guy: "Anyone who cares about FOSS vs. non-FOSS is likely to have no problem getting the list of non-FOSS components at freeslack.net and purging them."

Melikamp: "Slackware, on the other hand, is being shipped with non-free components, and has no option to remove them."

Guy: "I am not sure why you believe that Slackware has no option to remove non-free components. The link you yourself provided ( http://freeslack.net/ ) clearly says 'the purging procedure is relatively straightforward. Simply remove offending packages with removepkg, configure, compile, and install a linux-libre kernel, and finally remove the stock kernel packages (kernel, modules, firmware).' Anyone who cannot do that is unlikely to be happy with Slackware anyway, because that's the standard way of updating Slackware.[7]"

Melikamp: "Slackware itself offers no way, tool, or option to either install a fully free OS or make it free post-install. (Not that an option like that would make much of a difference.) The fact that one can deblob Slackware is irrelevant, since this page is about Slackware as released by PV and team."

At this point I am at a loss, because Melikamp keeps making a false claim ("no option to remove them", "no way, tool, or option to either install a fully free OS or make it free post-install."), I keep refuting the false claim by explaining exactly how one makes Slackware free post-install using nothing but the standard Slackware package tools and a list of which components to remove, and finally Melikamp says that the fact that there is a way to make Slackware free post install is "irrelevant". How is showing how to make Slackware free post-install not relevant when countering a claim that there is no way to make Slackware free post install? I do not see how we can move forward from here.

I am also a bit frustrated by the fact that Melikamp says "A good example of is Debian" when a comparison with Debian suits his purposes but tells me "Comparison with other distributions is also irrelevant" when I attempt to make a comparison with Debian.

At this point I do not see how any further replies from me on this topic will be productive, so I will finish with this: I oppose Melikamp's proposal for the reasons I have given in the thread above, and I am watching to see what the consensus is (in the discussion here or though an RfC), which of course I will follow whether I agree with it or not. I support there being a paragraph in FOSS that explains the difference between "out of the box" free, "select an option during install" free, "run a tool after install" free, "possible but a lot of hard work to strip out the non-free components" non-free and "nobody has ever successfully stripped out the non-free components" non-free. I think we should write that up, put it in the FOSS article, and link to it from here. -Guy Macon (talk) 16:37, 11 August 2013 (UTC)[reply]


Unfortunately, I am in no way able to provide a solution to this argument. As for free software, I have always considered the RMS point of view too radical. If a software developper decides to make his software non-free, I am completely fine with that. He makes the bytes, he makes the rules. Making a program non-free is a 100% valid market or else personal decision. But I DO care about open source because it provides a possibility to track trojans or spyware or else harmful or unwanted software. But as I said, I am not familiar enough with these topics to throw something worthwhile into this discussion.

Thus, I can only provide some purely formal hints or arguments:

Yes, Melikamp is wrong in stating that there is no way to make Slack free post-install. He himself gives a pointer to such a way. A pointer by the way, that I haven't been aware of. Well, there is no dedicated tool for purging. But it is a major trait of Slackware that there is an abundant lack of dedicated tools. Getting away with a modest bundle of standard tools - compilation, silent levitation of beer bottles and usage of the *pkg* suite - is the (beloved) Slackware way. That's all. That's enough.

Still, there is a difference between Slackware's spartan style and the description of Slackware in a Wikipedia article. Slack's way of making it hard for people who need long descriptions in order to get things done doesn't imply that an article on Slackware be Slackish as well.

What does "free and open source software" mean? Well, it means FOSS as defined by the respective Wikipedia article. The Slackware article points to the Wikipedia FOSS article. Therefore, it's not relevant what X or Y mean or Y thinks that Z means by using the term "FOSS" - it only is relevant what the WP FOSS article means. Thus, if Slackware is not free and open source in terms of the article it points to, the pointer could be considered "weak". Again, I can't judge if it actually is.

If we cannot find a convincing solution to that question, we should resort to other distro articles. This is not a 100% valid approach, because a statement does not become true only by complying to a majority of wrong statements. But if you can't decide on the truth of your statement, it is a plausible and common sense approach to go and check what others do.

How do other distro articles handle this? There is often a difference between the description in the text and the categorization in the info box. I will only go for the info boxes here:

  • Arch: Free and open source software
  • OpenSUSE: Free and open source software
  • Ubuntu: Free and open source software with proprietary components
  • Debian: Free software
  • Fedora: Free and open source software (with exceptions)
  • Mint: Free and open-source software and proprietary software
  • CentOS: Free and open source software
  • Mageia: Open Source
  • Red Hat: Open source
  • Gentoo: Free and open source software

Seems to be a bit messy. Plus: If you look at the info boxes on different Wikipedias (English, German, French, Spanish) - for the same entry you get different variants.

For instance UBUNTU: In the French Ubuntu page they simply omitted the "with proprietary components" clause. The Germans re-phrase it to just "open source". The Italians don't mess with FOSS and plainly state it is "GNU GPL". To the Dutch Ubuntu is "FOSS". In Denmark wikipedians describe the license as "GPL, GFDL".

Yes, RMS himself resp. his foundation, would consider none of the above listed OSes as free software distros, anyway. To be honest, I would appreciate it if the Slackware team could split its repositories in free and non-free etc. repos. But I am sure that they simply haven't got the time/man power or inclination to do so. Which is fine with me. Their task is huge already.

Conclusion: I have no idea what we ought to do. Maybe someone comes up with another perspective. After all, maybe it would be valuable to make a reference to the freeslack site. But I am not sure if the freeslack project is sufficiently complete to merit such a reference. As far as I can see, it only refers to Slackware 14.0 and seems to be work in progress. Anyway, this is a very valuable initiative. Perhaps though a pointer to it would not be justified, due to the project's incompleteness... Germanopratin (talk) 13:08, 15 August 2013 (UTC)[reply]

@Melikamp

As I said above, your initiative "Freeslack" is a valuable project. But there is one aspect of your effort I would like to bring out, precisely because it correlates to this discussion:

You do not differentiate between free software and open source software. It would be a crucial info if package X is not open source or if X contains parts that are closed source. You only focus on the license but spare this open source aspect which is even more important as it is also a security issue.

Or is it that Slackware 14.0 - as shipped on DVD - is completely open source? Germanopratin (talk) 17:52, 15 August 2013 (UTC)[reply]

@Germanopratin I have a hard time with understanding your point here. I am literally at loss at what you are trying to say. I do differentiate between free software and open source software, I know exactly what the difference is. In regard to Slackware, we've always considered it as non-free, and what we serve as FreeSlack is not only free in FSF's terms, but also adheres to FSDG. In particaular, we've made the decision to exlude Mozilla products, which may well be free/libre on paper, but they in fact serve sourceless binary blobs to users. And we, as anyone in their right mind, would never consider Slackware open-source, since it does not provide the source for some of the firmwares. It also fails OSI definition, but that's no surprise, since it's virtually equivalent to the FSF's free software definition. melikamp (talk) 07:57, 4 August 2016 (UTC)[reply]
Again, there are four basic ways a distribution can handle non-FOSS components. They are:
[1] 100% FOSS, no non-FOSS components made available by the distribution.
[2] 100% FOSS, adding non-FOSS is made easy (may require a recompile).
[3] Some non-FOSS, stripping non-FOSS out is made easy (may require a recompile).
[4] Some non-FOSS, no obvious way to create a 100% FOSS version.
Slackware is [3]. Richard Stallman will tell you that only [1] is real FOSS. Many people disagree. Pretty much everyone agrees that [4] is non-FOSS or perhaps a mixture of FOSS and non-FOSS. My point here is that the difference between [2] and [3] is trivial, and I really don't see a point in differentiating between [2] and [3] on individual OS pages. Literally nobody cares other than folks don't need Wikipedia to tell them what Slackware's source model is. --Guy Macon (talk) 12:33, 4 August 2016 (UTC)[reply]
I still disagree on a couple of points. For my money, Slackware is [4], since it does not afford a way to create "a FOSS version" (FreeSlack does that, and it's not "obvious"). Because of their (lack of) policy, a FOSS purist cannot use Slackware updates, so a deblobbed Slackware is no longer a complete living distribution, but rather an installation frozen in time. I completely disagree with Guy Macon's assertion that "Literally nobody cares other than folks don't need Wikipedia to tell them what Slackware's source model is". I believe it is of great worth to most users to know whether a software project like Slackware distributes closed-source software, and so almost certainly malware within it. Slackware itself has no official stance or statement, and documenting its blobs took research. And so I would definitely change the standing source model to something different, something that indicates the projects passes non-free blobs to users.
Not that we need to make this more complicated, but I also want to add this: "source model" itself is ambiguous, since it could mean just the the code produced by a project, or all the code distributed by the project. Slackware does not produce any non-free software in-house, but they do redistribute it. I think the redistribution part is more important, and it seems like what "source model" refers to, but may be Wikipedia should make this point more clear somehow. melikamp (talk) 17:50, 4 August 2016 (UTC)[reply]
Repeating the same false claim ("it does not afford a way to create a FOSS version") over and over does not make the assertion true. I have already explained exactly how one makes Slackware 100% FOSS post-install using nothing but the standard Slackware package tools and a freely-available list of which components to remove.
BTW, you may imagine that you are running a 100% FOSS computer, but your keyboard, hard disk, mouse, etc. run proprietary code that you cannot examine or change. See [ https://www.technologyreview.com/s/519661/nsas-own-hardware-backdoors-may-still-be-a-problem-from-hell/ ]. --Guy Macon (talk) 18:18, 4 August 2016 (UTC)[reply]
What is your point? It was us, the FreeSlack project, who originally explained how one makes Slackware 100% FOSS post-install, and now you repeated what we found, but unless you are a member of the Slackware team, I do not see how you can twist this into your [3] category, which is, and I quote: There are four basic ways a distribution can handle non-FOSS components. They are: [...] [3] Some non-FOSS, stripping non-FOSS out is made easy (may require a recompile). [...] Well, the Slackware project/distribution does not in fact "handle" anything, they do not even provide any licensing information, let alone a deblobbing how-to. Please compare again with Debian, which does provide libre kernel & repos, and can be argued to be your [3]. melikamp (talk) 00:23, 18 August 2016 (UTC)[reply]
This is completely irrelevant to the topic being discussed, and almost sounds like an ad hominem. I am well aware that a reliably free computer can only be printed by a free, self-replicating 3d-printer, but I do not see how this relates to the original topic of discussion: what exactly does the "source model" mean in software templates, and what should it be for projects like Slackware, based on their contents and practices. melikamp (talk) 00:23, 18 August 2016 (UTC)[reply]

Date Format[edit]

This is just a matter of style, but it could improve the readability of the text. We are using different date formats in the article, e.g.: "17 July 1993" versus " June 18, 2002".

Wikipedia style rules state: (1) both of the formats above are allowed (2) within a text there should be consistent use of just *one* format

So, which one should we use? Germanopratin (talk) 09:19, 11 August 2013 (UTC)[reply]


I prefer 17 Jul 1993 or 17 July 1993, because it puts the equivalent of the LSB on one end equivalent of the MSB on the other end, thus making sorting easier. Consider the following dates, which I sorted using a fairly standard word-aware sorting algorithm:
July 17, 1993
July 18, 1993
June 19, 1993
July 20, 1993
June 19, 1994
July 21, 1994
19 June 1993
17 July 1993
18 July 1993
20 July 1993
19 June 1994
21 July 1994
My sorting program (when I pick the RTL and by-word options) simply sorts by the rightmost word, then works its way leftward. To make July 17, 1993 work I would have to make a special right-left-middle version.
Of course I still had to tell the sorting program that June and July are months, because our months are not in alphabetical order. :( 17-07-1993 avoids this but has ambiguity problems if the day is 1-12. 1993-07-17 is the easiest to sort -- even MS-DOS's SORT gets it right -- but has the same ambiguity problem. Besides, those last two are not among the options given. --Guy Macon (talk) 17:24, 11 August 2013 (UTC)[reply]
I haven't considered parsing and sorting being an issue, but both are valid concerns. Another concern is readability of the text, which in a sense refers to a text's parsability when the parser is a human. I can concur to the LSB->MSB argument, for the sake of sorting - and of logic, as well.
As for readability: The best format for sorting would be a pure numerical format. But since people simply seem to prefer "June" to "06", a compromise seems to be necessary. The format "June 17, 2003" is bad in both respects. Sorting is difficult. And reading is, too: The comma that separates the year decreases readability, especially when the year is followed by another comma that belongs to the structure of the sentence.
Going along with your statement, which makes sense to me, I would suggest to use only the format DD-"MONTH"-YYYY. E.g: "17 June 2003". It's quite readable, and sorting only takes one extra mile (mapping the strings for the months to integers).
Germanopratin (talk) 11:01, 15 August 2013 (UTC)[reply]

Minor versions missing in the table of releases[edit]

I think that there is not reason to put them in the table.

See: 

======  ==========      ========
1.0.1   04/08/1993      0.99.12
1.0.2   05/09/1993      0.99pl12
1.0.3   15/09/1993      0.99pl12
1.0.4   01/10/1993      ?

1.1.1   12/12/1993      0.99.14
1.1.2   05/021994       0.99.15

1.2.0.1 01/04/1994      1.0
1.2.0.2 15/04/1994      1.0.8
1.2.0.3 21/04/1994      ?

2.0.1   18/09/1994      1.0.9
2.0.2   18/10/1994      1.1.54

8.1.01  19/06/2002      2.4.18

Better logo from the official Slackware site[edit]

Hi folks. The logo that's currently displayed by the article says that it's rendered from the logo on the Slackware website, but I don't think that it could have been as it's not using the correct font. In any case, there's a better SVG version of the logo available from the site from this link: http://www.slackware.com/grfx/shared/Slackware_web_logo.svg

I'd like to see this replace the logo for this article. I'm a bit of a Wikipedia n00b otherwise I'd make the edit myself, but if anyone can take a look I'd appreciate it. Volkerdi (talk) 04:31, 20 November 2013 (UTC)[reply]

I just replaced the logo. See
thumb|Slackware logo from the official Slackware site
and
https://commons.wikimedia.org/wiki/File:Slackware_logo_from_the_official_Slackware_site.svg
I have a couple of suggestions. First, assuming from your username that you are Patrick Volkerding (if you aren't, see Wikipedia:Username policy#Misleading usernames) it helps if you release any material that is likely to be used on Wikipedia under the CC-BY-SA 3.0 License. I asserted that the image only consists of simple geometric shapes and/or text and does not meet the threshold of originality needed for copyright protection and is therefore in the public domain (but still a trademark), but a CC-BY-SA 3.0 license removes all question.
Second, other Slackware material that we use can be found at
https://commons.wikimedia.org/wiki/Slackware#Logos_.26_mascot
If you have better versions of any of those, I can upload them for you. Likewise, if you wish to assert copyright I can start the ball rolling toward deleting the image. At least one of those images has a possible copyright problem; it says "I, the copyright holder of this work, hereby publish it under the following license" but I don't believe that the Wikipedia user who wrote that is the copyright holder. Can we go through them all and identify any copyright problems?
Third, the image that I replaced has a ® symbol, while the new one doesn't. Again assuming that you are Patrick Volkerding, which way do you want it? Right now the old image is used on the following non-english Wikipedias: ca.wikipedia.org, cs.wikipedia.org, da.wikipedia.org, es.wikipedia.org, et.wikipedia.org, eu.wikipedia.org, fi.wikipedia.org, fr.wikipedia.org, he.wikipedia.org, hu.wikipedia.org, id.wikipedia.org, it.wikipedia.org, ml.wikipedia.org, ro.wikipedia.org, ru.wikipedia.org, and sh.wikipedia.org. Once I get a definitive answer to the ® question, I can overwrite the old file and thus update all of the other Wikipedias.
Please feel free to drop me a line on my user talk page at User talk:Guy Macon or send me an email at https://en.wikipedia.org/w/index.php?title=Special:EmailUser/Guy_Macon if there is anything else I can do for you. Slackware literally changed my life. --Guy Macon (talk) 08:59, 20 November 2013 (UTC)[reply]
I get the impression that at _very_ least the Slackware logo should have a ™ symbol. I don't know if that particular logo is registered, so the R circle symbol may or may not be right. The ™ symbol will always appropriately support the fact that a logo is a trademark. I think some of the graphics on the Slackware site itself may be old, as they seem to occasionally change them up. Centerone (talk) 23:53, 21 November 2013 (UTC)[reply]
The ® symbol is correct.[8] I am going to wait a few days for a response from Volkerdi. I don't mind there not being an ® or ™ -- it is that way on the Slackware website -- but I also wouldn't mind if someone fired up a graphics editor and added an ®. --Guy Macon (talk) 01:03, 22 November 2013 (UTC)[reply]
Hey Guy, thanks for the Slackware logo update on the en article! Yes, I am in fact Patrick J. Volkerding (not sure how would be best to verify that if need be, but you could certainly drop me a line at my usual email, or possibly I could GPG sign something with the Slackware key). Please consider any Slackware logo that came from us to be licensed CC-BY-SA 3.0 (but without giving up any trademark rights). The SVG logo I pointed you to previously never had a ® and doesn't need one (or a ™ in my opinion). We never did register any logos (just the name), and I'm not too paranoid that someone will try to copy our logos anyway. Thanks again! Volkerdi (talk) 01:41, 22 November 2013 (UTC)[reply]

Help Needed From Patrick Volkerding[edit]

(Regarding the above section) I sent an email to the usual Slackware info address. The subject line is "Wikipedia email from Guy Macon"

Patrick, I know that you are busy, but any help you could give us in getting the details right would be very much appreciated. This is the right place to do that. (There is a nice guide for how to suggest changes to a page about yourself or your company at Wikipedia:Plain and simple conflict of interest guide.)

For an example of where help would be appreciated, see Talk:Slackware#ANNOUNCE: Slackware Linux Distribution 1.00.

I went to a lot of trouble reconciling the fact that we have two reliable sources (slackware.com and your original 1993 posts to comp.os.linux and comp.os.linux.announce) that give us different release dates for Slackware 1.00. My conclusion was that slackware.com got wrong information from Google groups. It would be very helpful if you either could confirm that and post the correct information on slackware.com or tell me I am wrong, that the slackware.com date is correct, and that it is the USENET posts that have bad dates.

Also helpful would be you taking a look at our Patrick Volkerding page, checking it for errors, and posting any suggested changes at Talk:Patrick Volkerding.

Again, I don't want to add to your workload, but I would like Wikipedia to be as accurate as possible. --Guy Macon (talk) 16:10, 22 November 2013 (UTC)[reply]

This is to document the fact that I got the following email (Email and IP addresses removed; I can supply them if someone has a reason to see them.) 

 Date: Fri, 22 Nov 2013 23:13:38 -0600
 From: "Patrick J. Volkerding"
 
 > From: Guy Macon [mailto:[deleted]@[deleted]]
 >
 > Hi! I am trying to confirm that the Wikipedia user at
 > https://en.wikipedia.org/wiki/User_talk:Volkerdi is Patrick J. Volkerding.
 > See discussion at
 > https://en.wikipedia.org/wiki/Talk:Slackware#Better_logo_from_the_official_Slackware_site
 
 Hey Guy!
 
 Yes, it's me.  I'll try to get to some of your questions this weekend if 
 I find a bit of time.
 
 Take care,
 
 Pat

The above email was sent to a new email address that I created just for this, and all of the headers indicate that it was sent from Slackware Inc. Identity confirmed; nobody else could have known what email address to send a spoof email to.

I am going to send a followup message asking Patrick if he could find time to:

  • Take a look at our Slackware and Patrick Volkerding pages, check them for errors, and post any suggested changes on the article talk pages.

--Guy Macon (talk) 14:59, 9 April 2014 (UTC)[reply]

No response so far. I am going to try again. --Guy Macon (talk) 12:41, 4 August 2016 (UTC)[reply]
I wouldn't worry about the release announcement, it could be that he had re-posted the earlier announcement later in the year, and then when he went to look for a copy of it just grabbed that one for posting on the site. The usenet messages are date stamped, so it's reliable and accurate. I would think it's not a big enough concern for him to bother with changing the text on slackware.com. He's probably less obsessed with accuracy of dating than some folks here. As to the other things, the pages look pretty accurate. As far as images go, what images do you think are needed? Installed system images can be provided by anybody who can download and install slackware. Centerone (talk) 15:40, 4 August 2016 (UTC)[reply]
The usenet messages posted on slackware.com are date stamped with an incorrect, modified date and time.   :(   Call me "obsessed with accuracy" if you want. but I think that is worth fixing. --Guy Macon (talk) 18:29, 4 August 2016 (UTC)[reply]

Distrowatch? Why is this even a thing?[edit]

Why is the DistroWatch page ranking even a thing? Who cares how many people visit a webpage about Slackware on some site? Why do I need to visit a page on a site about a distribution if I can just get the news about that distribution elsewhere, such as from the distribution itself? Sure, I could see reading the front page "latest news releases" to get information about a number of distros at once, but why would I go to the page about the specific distro? I say we should just remove the entire distrowatch section. It's meaningless. Centerone (talk) 16:27, 16 March 2015 (UTC)[reply]

Distrowatch is the standard way of judging the popularity of Linux distributions, which cannot be measured by units shipped or dollars received. There is no good reason to abandon such a useful metric. --Guy Macon (talk) 20:45, 16 March 2015 (UTC)[reply]
Didn't there use to be a distribution user registry somewhere? Surely that is more of a useful metric than how many people might have looked at a page on this website. I just looked at a number of linux distro wikipedia pages and while they may get some information from distrowatch, they seem to do so more to reference factual and meaningful information for the most part and not just how popular they are according to some silly metric based on web traffic to a page. Certainly this information is not deserving of an entire section all to it's own and paragraph of text. Centerone (talk) 22:57, 16 March 2015 (UTC)[reply]
If distrowatch is a way to measure popularity, then the section should be named "Popularity on Distrowatch", and spell that out better in the paragraph. Right now it is talking about "Use" but leaves me without an impression that is was discussing use in slackware, but rather talking about something in distrowatch. Which leads me to one other point. You may think that distrowatch is standard for measuring popularity, but I and others there are better ways. For example, I use distrowatch for finding out things about distros I do not use, which is why I go there. So I hardly click on slackware because I don't need to, and I use the distro! So rather than correctly describing distrowatch popularity as a measurement on the slackware article, please move distrowatch to a distrowatch article, or an article on measuring popularity of linux distributions, and you can have at it there. It doesn't belong here. — Preceding unsigned comment added by The3dfxdude (talk • contribs) 20:52, 19 March 2015 (UTC)[reply]
More info. The page used to say [this], in fact, had a more-rounded discussion on popularity, not use. The editor decided to delete most of the content, leaving the vague "Use" section centered on distrowatch. Now I am not going use reason that it should be put back as it were, because if [this] was a problem, then distrowatch is more-so. My vote is to delete the section. The3dfxdude (talk) 21:14, 19 March 2015 (UTC)[reply]
Because two other Wikipedia editors think it should go, I am inclined to wait two or three days to see if anyone else has an opinion on this and then go along with the majority. See WP:CONSENSUS. --Guy Macon (talk) 21:35, 19 March 2015 (UTC)[reply]
The objections made about popularity and usage are *totally* correct. When I came up with this new paragraph I named it "popularity". Then some dude named #Thumperward# came along and changed everything and flushed dozens of lines of text down the drain. He is some sort of admin, so I accepted his mods and deletions. But to be honest it also took away all the fun I had with contributing to this WP page. I am still now sure, if his actions were good or not. I guess they are good, as he will have a more objective approach.
So, why such a parapraph, anyway? Well, I added so much stuff to this page. Sometimes also for the sake of adding. I felt that such a venerable system like Slack merited an ample text. I am not sure, if it really is necessary to give some info about the popularity or usage of any Linux distro. So if some guys feel, it is superfluous, I am fine with that. On the other hand, Slackware is a special case, as it is very venerable, yet its relevance seems to be dramatically vanishing, too. So it might be fair to inform ppl about its (dimishing) popularity (which in a way reflects actual usage). To tell the reader, who knows nothing about Linux distributions, that this distro had a great past but today is a bit of a niche OS, might be valuable info. Well, it might be just inane gossip to others.
A system's popularity is very, very hard to measure. It's certainly true that Distrowatch does not serve as a genuine statistical tool. Certainly for the BSD's it will be just useless. Maybe even for Linux distros, it is not a viable source of information. On the other hand, it is cited a lot when ppl refer to popularity trends. Brian Landuke, I think, stated that DW is not a tool for measuring recent data, but that it is a good approximation of usage trends. So it may be. I don't know. But I feel he made a good point there.
Generally speaking, why should you care about usage? Well, as tools like DW give you trends, they might be relevant. Actual usage might be less relevant than trends (!) of usage. If you decide to go for a system, the outlook of its usage might be an investment decision: Should I invest time and knowledge into that OS? For some ppl such things DO matter - others don't care. Obviously, I as a Slack user do not care, how many people actually use Slackware. But if you are new to Linux, you might decide to go for a popular system - for the notorious reasons, like support etc.
To sum things up: If someone wants to delete this section, I will not object. But I am not going to delete it myself ;-)
Germanopratin (talk) — Preceding undated comment added 13:25, 14 June 2015 (UTC)[reply]
@ The3dfxdude
EXACTLY!!! When I wrote that section I tried to give - like you said : a "more-rounded discussion on popularity, not use".
Enter thumperward: The deletion of so much content and the renaming of the section with "USAGE" made no sense. The result was just, well ...
I think he did it all in good faith, but it would have been better to drop all of it than to keep a mere fragment and tag a misleading title onto it.
Again, I am not sure what to do with it. Maybe we should wait for a fifth or sixth opinion. I don't know...
Germanopratin (talk) — Preceding undated comment added 13:42, 14 June 2015 (UTC)[reply]

Design Philosophy clarification?[edit]

Clarification bugs are posted in this section at "software purity" (where Slackware is promoting the idea of distributing softwear with as little modification as possible, "as close to the original programmers intent as they can," as they put it). Also there is another bug where they discuss how it might be easier for UNIX users to feel familiar with. This refers to the Slackware philosophy to attempt to be "the most UNIX-like Linux distribution." See the distribution README files. Leeeoooooo (talk) 17:04, 31 August 2015 (UTC)[reply]

Support[edit]

unofficial support for Slackware is available in the 'Slackware' forum om the LinuxQuestions web site. Many of the dev team drop in there rather regularly... Leeeoooooo (talk) 18:11, 31 August 2015 (UTC)[reply]

The section titled "Support" discusses the question, how long a release is actively maintained in terms of security fixes. This should be stated more clearly. User support as addressed above is not offically offered. --Boobarkee (talk) 09:56, 2 September 2015 (UTC)[reply]

Change History section?[edit]

The history section doesn't really seem to chronicle the history of Slackware itself so much as just an almost-bullet-list of each version and the changes associated with it. I am thinking it would be beneficial to shorten this down to the major changes (Slackware 4-7 jump, removal of GNOME, switch from KDE 3.5 to 4.x, adding Slackware64) but in greater detail, rather than the notable changes from (almost) every release. With the way it currently is, it feels like you should have every release listed in there (it is missing several versions), but that seems like overkill. I also could not find any substantial reason for the separation of the History section to 1993-2003 and 2004-present. There didn't seem to be any major shift within Slackware to mark that separation and it looks like it was done just because of the large amount of items covered... which I think it more of a reason to minimize what is covered in there.

I propose to shrink the History section down to just a few major points of Slackware, and then add a column to the release table of "notable changes". It prevents duplicate information and consolidates the important parts. Here is a rough idea of the addition to the table (small section of copy/paste from the table I've been editing on my local machine):

x86 release history
Version Release date End-of-life date Kernel version Notable changes
Old version, no longer maintained: 12.2 2008-12-10 2013-12-09[1] 2.6.27.7 (patched to 2.6.27.31)[1]
Older version, yet still maintained: 13.0 2009-08-26 No EOL announced 2.6.29.6 Introduced Slackware64, an official 64bit port, and switched from KDE 3.5 to 4.x
Older version, yet still maintained: 13.1 2010-05-24 No EOL announced 2.6.33.4 Added PolicyKit and ConsoleKit and switched to the libata subsystem
Older version, yet still maintained: 13.37 2011-04-27 No EOL announced 2.6.37.6 Added support for GPT and utilities for the Btrfs filesystem
Older version, yet still maintained: 14.0 2012-09-28 No EOL announced 3.2.29 (patched to 3.2.45)[2] Added NetworkManager. Removed HAL as its functionality was merged into udev
Older version, yet still maintained: 14.1 2013-11-04 No EOL announced 3.10.17 (patched to 3.10.103)[3] Added support for UEFI hardware
Current stable version: 14.2 2016-06-30 No EOL announced 4.4.14 (patched to 4.4.19)[4] Added PulseAudio and VDPAU and switched from udev to eudev and ConsoleKit to ConsoleKit2
Latest preview version of a future release: -current rolling — 4.4.23[5]
Legend:
Old version
Older version, still maintained
Latest version
Latest preview version
Future release

References

  1. ^ a b 12.2 ChangeLog.txt
  2. ^ ftp://ftp.slackware.com/pub/slackware/slackware-14.0/ChangeLog.txt
  3. ^ ftp://ftp.slackware.com/pub/slackware/slackware-14.1/ChangeLog.txt
  4. ^ http://slackware.cs.utah.edu/pub/slackware/slackware-14.2/ChangeLog.txt
  5. ^ "The Slackware Linux Project: Slackware ChangeLogs". Retrieved 15 Dec 2015.

I'll be working locally on revising the History section over the next few days (possibly longer, depending on how much time I can spare), as well as populating the "notable changes" section of the table (mainly from the History section, but I'll also dig into the announcements and changelogs to see if I can come up with something notable for the releases not mentioned in the current History. If I don't hear any complaints here, I'll probably make the change sometime next week (assuming the Hurricane Matthew doesn't affect us too bad in VA). I welcome any comments, criticism, or complaints! --Bassmadrigal (talk) 19:14, 5 October 2016 (UTC)[reply]

I agree, if the history section is going to be divided into "eras", it should be a little finer-grained than currently, and based on significant events that break continuity with earlier releases (package system overhaul, dropping Gnome, etc.), but it might be just as well to make it a single, concise section. I may pitch in here and there, if anything strikes me, any of which edits should be considered merely tentative suggestions. On a related note, the word "purity" in the design philosophy section kind of bugs me (and probably comes across as pretentious to readers), but I can't really think of a softer term that conveys the "don't mess with upstream sources if you don't have to" approach... anyone? --Junkyardsparkle (talk) 20:34, 5 October 2016 (UTC)[reply]
Seems like an improvement over what we have now. I say go for it. --Guy Macon (talk) 04:20, 6 October 2016 (UTC)[reply]
Thanks for the encouragement. I spent a lot of time at work today (don't tell my boss ;) ) and got all the major changes done. I still need to add references to the "Notable Changes" section in the table, probably a few more readings through the history section, and searching through the ChangeLogs and Announcements to see if I can find more notable changes for the table. Feel free to dig through and make changes (if you can... I'm not sure how the sandbox works, as this is my first time using it). Or feel free to put any suggestions here.
https://en.wikipedia.org/wiki/User:Bassmadrigal/sandbox
Also, thanks Guy for fixing the references for the table. — Preceding unsigned comment added by Bassmadrigal (talk • contribs) 18:10, 6 October 2016 (UTC)[reply]
Ok, I finally felt like everything meshed well enough to update the main page. I'm sure issues slipped past my eyes, so dig through to find any mistakes I left in there and feel free to add more notable changes if you come across any. I ended up deciding to split the history section into the birth of Slackware and further development, because without it, the section seemed quite long, plus there were two obvious subsections being covered. I'm open for any fixes, suggestions, gripes, or complaints about my updates.--Bassmadrigal (talk) 14:43, 14 October 2016 (UTC)[reply]

Think it's time to remove the relying too much on primary sources warning?[edit]

I've been tinkering on this page for quite some time and I was curious how accurate the following warning still was.

So, I did some work in the shell... First I grabbed the "source" of the page and put it in a text file so I had all the references in a single file. Then I used some fancy grep command I found to extract the base urls with a bunch of pipes to consolidate and count those, then some other greps to grab Slackware-based urls compared to the others and added them together. After checking everything, I found that there's 45 references to sites that do not have slackware in the name vs 29 that do.

Does anyone feel that there's still too many references to the primary source? Or is it time to remove that warning?

Here's the output if anyone wants to verify my work: 

 grep -Eo '(http|https)://[^/"]+' wiki-slack | sort | uniq -c | sort | grep -i slackware | awk '{print $1}' | paste -sd+ - | bc
 29
 grep -Eo '(http|https)://[^/"]+' wiki-slack | sort | uniq -c | sort | egrep -vi slackware | awk '{print $1}' | paste -sd+ - | bc
 45

     1 http://arm.slackware.com
     1 http://connie.slackware.com
     1 https://docs.slackware.com
     2 http://arm.slackware.com
     2 http://docs.slackware.com
     2 http://mirrors.slackware.com
     2 http://slackware.mirrors.tds.net
     3 http://slackware.com
     5 http://slackware.cs.utah.edu
    10 http://www.slackware.com

     1 http://distro.ibiblio.org
     1 http://en.wikipedia.org
     1 http://freeslack.net
     1 http://ftp.df.lth.se
     1 http://groups.google.com
     1 http://isbndb.com
     1 http://rlworkman.net
     1 http://slackintosh.workaround.ch
     1 http://www.bisdesign.ca
     1 http://www.datamation.com
     1 http://www.ibiblio.org
     1 http://www.itpro.co.uk
     1 http://www.linux-mag.com
     1 http://www.linux.com
     1 http://www.linux.org
     1 http://www.linuxjournal.com
     1 http://www.linuxquestions.org
     1 http://www.pcworld.com
     1 http://www.slackbook.org
     1 http://www.techradar.com
     1 http://www.trinitydesktop.org
     1 https://books.google.com
     1 https://github.com
     1 https://lwn.net
     1 https://slackbuilds.org
     1 https://sourceforge.net
     1 https://tech.slashdot.org
     1 https://www.linuxquestions.org
     2 http://ftp.nluug.nl
     2 http://www.slackwiki.com
     2 https://cinnamonslackbuilds.github.io
     2 https://mateslackbuilds.github.io
     9 http://distrowatch.com

Sorry for the wall of text --Bassmadrigal (talk) 01:36, 24 November 2016 (UTC)[reply]

Well, you could perhaps diff the results of scraping the links from the version of the page to which the tag was added by Thumperward (talk · contribs), and see if the improvement seems substantial. It could always be freshly re-tagged if anyone still feels that way. --Junkyardsparkle (talk) 06:48, 24 November 2016 (UTC)[reply]
Good idea. This shows there's been substantial improvement in using additional sources. There were 31/22 (*.slackware.com/other) sources compared to 29/45 now. We've more than doubled the amount of secondary/tertiary sources.
 grep -Eo '(http|https)://[^/"]+' old-wiki-slack | sort | uniq -c | sort | grep -i slackware | awk '{print $1}' | paste -sd+ - | bc
 31
 grep -Eo '(http|https)://[^/"]+' old-wiki-slack | sort | uniq -c | sort | egrep -vi slackware | awk '{print $1}' | paste -sd+ - | bc
 22
Thanks for the idea--Bassmadrigal (talk) 02:35, 27 November 2016 (UTC)[reply]
  • Support removing the "this article relies too much on references to primary sources" notice. There are sufficient secondary sources for removal. --Guy Macon (talk) 08:30, 24 November 2016 (UTC)[reply]
Heh, I don't think you need a lot of votes on this like it's an RFC. Go for it. Also, while you're at it, I wonder if you could use the process you used for this to automate a bot to check other articles that have this warning on them. Centerone (talk) 19:43, 24 November 2016 (UTC)[reply]
I figured it wouldn't need voting, but I didn't know at what point it's considered to be well-sourced by secondary/tertiary sources. A comment above suggested doing a comparison, and we've more than doubled secondary/tertiary sources from 22 to 45 (primary sources went from 31 to 29 now). As for creating a bot for wikipedia, I wouldn't have the first idea on where to even start. I'm not great at programming. I just know enough of the shell to be dangerous--Bassmadrigal (talk) 02:35, 27 November 2016 (UTC)[reply]

Articles should never be using primary sources to reference statements. As far as I'm concerned, having roughly a quarter of all references be primary is most certainly not grounds for removal of a primary sources tag! This is one of the most common failings of tech articles on here: editors assumes that for some remarkable reason, a project's own documentation is the only source that's ever needed to cite something. Plainly it is not the case for nearly any other subject that we take its own output as the best reference.

To an extent, this is of course intertwined with another nearly-inevitable failing of tech articles, namely that trivia such as endless lists of release dates is somehow interesting or relevant to a general-purpose encyclopedia. If our biographies were written like this we'd list everyone's achievements by birthday (and source it solely to their own diaries or CVs).

What this article needs is a proper peer review, not people writing shell scripts to argue for the removal of the cleanup tags that are meant to help bring it up to scratch.

Chris Cunningham (user:thumperward) (talk) 13:54, 26 November 2016 (UTC)[reply]

I strongly disagree with your assertion that "Articles should never be using primary sources to reference statements" (emphasis in original.) That may be what you want our policy to be, but it does not describe what our policy actually is. Here is what WP:PRIMARY has to say:
"Policy: Unless restricted by another policy, primary sources that have been reputably published may be used in Wikipedia, but only with care, because it is easy to misuse them. Any exceptional claim would require exceptional sources. Any interpretation of primary source material requires a reliable secondary source for that interpretation. A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge." (Emphasis (including the bold, emphasized, and colored word "Policy") in original.)
Let us examine the first and last primary references used in this article:
"Slackware aims for design stability and simplicity and to be the most 'Unix-like' Linux distribution.[1]" (cites http://slackware.com/info)

References

  1. ^ General Information at Slackware's website
"Slackware ARM can also be installed on a PC running QEMU[1]" (cites ftp://ftp.arm.slackware.com/slackwarearm/slackwarearm-current/INSTALL_QEMU.TXT)

References

  1. ^ Installation instructions for Slackware ARM (Qemu)
Both of the above are primary sources, used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge. And in both cases they are the best sources for those statements. --Guy Macon (talk) 17:15, 26 November 2016 (UTC)[reply]
By no means was this intended to be an argument on removing the tag. It was merely something I had been curious about (what numbers would be good enough to remove the tag), so I decided to count how many instances were primary sources vs other and then just ask the question to see what others thought. It was just much easier to use the shell to figure it all out rather than counting them each manually after hovering over each reference item (and in actuality, the number would be a little higher since I know there's at least 1 book reference that wouldn't be caught by my little shell one-liner). But in addition to Guy's comments above, what type of sources would you like to see here? Slackware isn't in the news much anymore, and most items that are being referenced would only be things that are covered in official sources. They are factual items that don't have any interpretation. If we were to happen to find another source, they'd just be sourcing things from the original source (like one of the FAQ entries about release date speculation).--Bassmadrigal (talk) 02:35, 27 November 2016 (UTC)[reply]
Well, that's rather the problem, isn't it. We have this long article about a Linux distribution which hasn't really been of mainstream appeal since the very early days of such things, which nonetheless has several special characteristics that distinguish it as an encyclopedia subject, and yet we've hidden all the more important stuff amongst labouriously-constructed boilerplate because someone somewhere decided that all articles on Linux distributions should look identical. To that end we have huge amounts of trivia included which is sourced either directly to the project's own release notes (which I note aren't even consistently sourced to the same domain) or to routing coverage from the technical press. So it's very much the case that what could be a routine problem (overuse of primary sources) is in this case simply a symptom of a bigger issue (an article written to conform to some particular structure, rather than on the subject's own merits).
Addressing the former won't fix the latter by itself, but it is obviously not a good argument that the latter means that the former doesn't need fixed (which is basically what Guy Macon is saying). Chris Cunningham (user:thumperward) (talk) 11:17, 27 November 2016 (UTC)[reply]
I pretty much agree with Chris about the improvements that this article needs, but I don't think tagging the article regarding primary source overuse in cases where WP:PRIMARY clearly allows them (and, I would argue, they are vastly superior to secondary sources) is the answer. I say we remove the tag. I believe that if I post an RfC on the question that will be the result. --Guy Macon (talk) 12:34, 27 November 2016 (UTC)[reply]
I've actually looked at other Linux distro articles to see how the Slackware article compares, and I feel like it doesn't really follow some unspecified standard. If you look at Debian, yes, there are some similarities (which is bound to happen with articles covering similar subjects), but there are also a vast number of differences that, to me, clearly shows there is no template that various distros are following. Indeed, if you look at Ubuntu (Operating System), Arch Linux, and Gentoo Linux, they all are quite different from each other. I feel like the article covers the important aspects of Slackware that should be covered in an encyclopedia. In my personal opinion, I feel that only the "Design Philosophy" and "Repositories" sections need a decent amount of work, and both are on my todo list (maybe the "Name" section too, but I haven't given it much thought yet). But if you feel that the Slackware article contains too much trivia, what do you suggest be changed/removed?--Bassmadrigal (talk) 18:54, 27 November 2016 (UTC)[reply]
So, would it be a fair assessment to conclude that the current tag is unhelpful, not because it indicates a problem where there is none, but because it states the problem in overly simplistic terms that are unlikely to lead to the desired improvements? --Junkyardsparkle (talk) 20:34, 27 November 2016 (UTC)[reply]
The current tag indicates a problem where there is none. Thumperward restored it based upon what he wants our policy to be, not on what our policy is. As explained above, our policy (WP:PRIMARY) specifically allows primary sources to be used the way they are used in this article. --Guy Macon (talk) 21:09, 27 November 2016 (UTC)[reply]

Separate version history article?[edit]

Look at Ubuntu (operating system)#Releases and Ubuntu version history. Should we do something similar with Slackware? --Guy Macon (talk) 12:34, 27 November 2016 (UTC)[reply]

There used to be one (Slackware version history), but it was removed in April 2016 due to it being "not notable for separate article" and was redirected back to Slackware. However, the previous "article" (I use that term loosely) basically mimicked DistroWatch, but with a lot less info. I imagine if someone were to take the time to build one like Ubuntu's it would be notable enough, but I was finding it to be hard enough getting enough info for some of the "Notable changes" on the version table that I added. Maybe it was just because I didn't want to dig through changelogs and compare the newer changelogs with the older ones. But if someone were to undertake it, I'd try to contribute.--Bassmadrigal (talk) 19:07, 27 November 2016 (UTC)[reply]

Repositories Section Overhaul[edit]

I've spent the past few weeks on and off (especially with the holidays) working on the repositories section. However, I ended up deviating quite far from the original version, so I wanted to get some thoughts on it before I switched it in the article itself. I currently have it as a subpage in my sandbox. Feel free to check it out and let me know what you think. I'm open to any comments, suggestions, or criticism. Thanks for your time! --Bassmadrigal (talk) 20:00, 4 January 2017 (UTC)[reply]

Since there were no comments or complaints, I updated the repositories section today. --Bassmadrigal (talk) 03:57, 15 January 2017 (UTC)[reply]

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 7 external links on Slackware. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 18:32, 26 July 2017 (UTC)[reply]

I replaced all links to mirrors with mirrors.slackware.com for uniformity. I also switched Slackware Arm's reference from ftp to http, which should fix the issue. This fixes all dead links for mirrors (and all known dead links except for the ibiblio.org one). --Bassmadrigal (talk) 23:59, 20 December 2018 (UTC)[reply]

Anyone know why mirror.slackware.com links are showing up dead?[edit]

As the subject says, based on this edit, mirror.slackware.com links are marked as dead. However, they work fine on my system. Is this because of the "mirror brain" (or whatever it's called) that's used, which automatically routes connections to a local mirror? I went through and redid all the links to changelogs to point to that domain, and if it's going to cause deadlinks to appear, we should adjust them to a different site (but one that is used uniformly, because we were using all sorts of different mirror addresses before I updated it). Thanks for any insight on this! --Bassmadrigal (talk) 00:54, 5 March 2019 (UTC)[reply]

Thoughts about "No EOL specified"[edit]

For those old Slackware releases that doesn't have an EOL specified (or maybe even all of them), how about having a separate table entry with the date of "Last ChangeLog update" or some such? For those still actively updated one should probably put e.g "Still active" instead of date, so people doesn't have to update the wiki page for every update. Just some loose thoughts coming up a late night. Maybe others have thoughts about it too? 193.71.28.50 (talk) 00:57, 7 February 2021 (UTC) KarlMag[reply]

I'm disappointed.[edit]

Everytime I correct this page, some idiot(s) screw with this page;

Soo, I'm gonna say this once: Slackware has Plasma, Mate, Cinnamon, XFCE under live image, open your goddamn eyes!

Do not edit this page if you know nothing. Also atleast don't change back to image of to Slackware 14.1, Set good image of 14.2.

I'm truly disappointed from management way of wikipedia, I'd not contribute to such pathetic platform ever again. 5.115.150.102 (talk) 09:58, 25 November 2021 (UTC)[reply]

Sorry, I missed this entry on the talk page.
I am the "idiot" correcting your misinformation and the one who got the page protected status to prevent further edits from you (since you switched . However, I tried several times through the edit summaries, posted on your own talk page, and even emailed you based on previous correspondence we've had explaining why you were incorrect.
What I've repeatedly tried to explain to you is Slackware does not have an official live image. Slackware Live is 3rd-party and provided by Eric Hameleers (aka AlienBOB) and is not officially produced by Patrick Volkerding. The default interface for Slackware is the CLI as Volkerding has Slackware default to runlevel 3. As you are well aware, Hameleers provides several flavors of Slackware Live that default to the other DEs you were trying to list, but, as I've tried saying several times, Slackware Live is not an official Slackware product. It is no different than Slam64, Slint, or any other spinoff of Slackware (even if it sticks extremely close to the official Slackware packages).
Unless it is developed and produced by Volkerding and he labels it as Slackware, it is unofficial and has no place in the infobox. Please feel free to reach out if you have further questions. --Bassmadrigal (talk) 01:02, 25 February 2022 (UTC)[reply]

Slackware's official repository[edit]

Hi In this section we have "There are no official repositories for Slackware."

Then what is this:!

https://packages.slackware.com/

All official software packages(pre-compiled + source) are there. http://yousha.blog.ir/ (talk) 13:39, 22 August 2022 (UTC)[reply]

ARM 32 bit official porting ceasing reasons[edit]

I removed the recent addition of the reasons for 32bit. Is not true that:

  • 32bit hardware was inhibiting development (building packages could be slower than x86, but it does not inhibit the development)
  • Hardware limitations block the adoption of the latest technologies (all packages were built in the unofficial 32bit ARM hard-float porting: https://bonslack.org/bonslack_armv7hl-current/ )
  • Most of the other mainstream distributions ceased support for 32bit ARM (Arch Linux ARM, Debian, armbian, Fedora ARM still supports 32bit ARM; only Ubuntu has dropped ARM 32 bit support)

The main reason of ceasing the 32bit ARM support is the lack of time/resources (recently, also due to the increase of the cost of electricity in Europe: https://arm.slackware.com/ ). Lucabon (talk) 20:57, 23 December 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Slackware&oldid=1205324053"