From http://polishlinux.org/choose/comparison/?distro1=Debian&distro2=Slackware Packages divided into groups depending on their purpose: A (base), AP (most important apps), D (development), E (Emacs), F (docs), GNOME, K(source code), KDE, KDEI (KDE localization), L (libraries), N (networking), T (Tetex/LaTeX), TCL, X (X-window system), XAP (X apps) i Y (games)
/etc/inittab set the default runlevel for your installation:
# These are the default runlevels in Slackware: # 0 = halt # 1 = single user mode # 2 = unused (but configured the same as runlevel 3) # 3 = multiuser mode (default Slackware runlevel) # 4 = X11 with KDM/GDM/XDM (session managers) # 5 = unused (but configured the same as runlevel 3) # 6 = reboot # Default runlevel. (Do not set to 0 or 6) id:4:initdefault:
Daniel de Kok aims this up-to-date introduction to Slackware Linux 10.2 at "people who have little or no GNU/Linux experience". An excellent resource for those who are new to Slackware Linux. http://www.slackbasics.org
Mikhail Zotov illustrates how aliases and functions can help to speed up many everyday operations in bash. http://slackworld.berlios.de
"There is one distribution you would seldom hear about and yet, it is uniquely qualified for heavy-duty desktop usage". Eduardo Sanchez in a three part article on how to setup Slackware. http://www.ofb.biz/modules.php?name=News&file=article&sid=315
Joe Brockmeier explains how Slackware initialises services, what the various runlevels are and how to add or remove services from the default install. http://www.ibm.com/developerworks/linux/
"Writing a tips article is tricky. Veteran users want incredibly good tips. New users want tips that bring accessibility and understanding to Slackware. Find that balance here." http://www.dualisanoob.com
Revised version of the Slackware Linux Essentials book available for reading online. http://www.slackbook.org
A forum dedicated to all things Slackware. If you have got a question related to Slackware, this is a good place to ask. http://www.linuxquestions.org/questions/slackware-14/
> Please post some helpful links for introductory on Slackware. For example, > does Slackware do its version upgrade the original RedHat way, or the Debian > way. Are Slackware .tgz files binary releases or source releases, etc, that > sort of things.
I think that you will find a lot of answers here:
documented on: Jun 03, 2007, flux
> thanks. Well, somebody care to give me a quick reply to my OP, while I'm > searching for the needles in the hays...?
Slackware packages (.tgz) are normally used for binary releases although they do very often include some development files (include headers) to help build related-software.
Slackware packages don't normally include full source, tar.gz/bz2 are frequently used instead. Although, they too (tar.gz/bz2) can include binaries but are not true Slackware packages.
The .tgz format is essentially the same as tar.gz, the change in extension helps distinguish it as a Slackware package. Most of the time, they should contain an install directory with a package description including version/author/website/build-flags, etc; listing of any essential/optional dependencies; in addition to a script, if needed, to create symbolic links & remove files, etc.
The links posted above by flux and myself should be a little more descriptive and helpful, hopefully.
documented on: Jun 03, 2007, pingus
> The links posted above by flux and myself should be a little more > descriptive and helpful, hopefully.
Definitely! thanks a lot for your detailed explanation too, pingus!
I quickly skimmed through all the urls listed above, but haven't noticed where the slackware upgrading & versioning is covered.
FYI, as for the upgrading & versioning in other distros,
The original RedHat way is more or less a cut and dry method. Every new OS version upgrade is a big jump from previous version. People would either wait for the next big jump, or refer to 3rd party for version upgrades of each individual tools.
The Debian way is more or less a milestone way. The Debian repository is a living and breathing system that updates itself whenever new version of each individual tools is read. When the time is right, they call it a major OS version release. After the major OS version release, only security update are released for each individual tools, while there are official methods to keep up with the living and breathing system.
documented on: Jun 05, 2007, xpt
Slackware have major releases (version 10 or 11) with a fair few number of changes but is more evolutionary than revolutionary. Subsequently, after the major release, sometimes several point-releases (version 10.1, 10.2) are issued that build upon the prior release.
I find the release schedule to be not too frequent and similarly not to distant either.
There is also the slackware-current repository which contains the very latest in slackware packages. Beware since it frequently updates and hence the occasional package is subject to glitches. Although, these isssues are quickly reported and resolved in virtually no time.
Most users will find the slackware-current repository to be perfectly stable or they can patiently wait for a new release, what ever suits them best.
The following is a small collection of package-management related software:
documented on: Jun 05, 2007, pingus
place scripts named with 'S' as startup scripts in the appropriate runlevel ie runlevel 3
/etc/rc.d/rc3.d/S90.somestartupscript
*make sure this file is executable* ie
chmod +x
to address the kdm/gui runlevel4, I simply create a symlink ie
ln -s /etc/rc.d/rc3.d/S90.somestartupscript /etc/rc.d/rc4.d/S90.somestartupscript
S90 is part of the script name to help sequence scripts .. ie S01.a, S02.b will execute in the right order upon startup
some sample lines I like to have in my startupscripts
#!/bin/bash echo running $0 $* #commands to run
for shutdown scripts use scripts named with a K instead (Kill?) ie K90.shutdownscript
scripts should be published with a module, but if file permissions are not relevant, you can use the rootcopy feature of slax …
I just looked at page 1 of the "slax5 look here first" and found a startup module example listed as well http://www.slax.org/forum/viewtopic.php?t=18759&start=0
documented on: 2007-08-27, guest - csmith
It is "K" for shutdown. Uselivemod from Slax6rc4 launches all scripts found under rc.d while for slax 5 it must be in rc3.d
documented on: 2007-08-29, rattata
> I would like to enable SSH access to my slackware box from the outside world.
It should be setup pretty well by default. You shouldn't have to do much of anything to get it working except start the server, unless you need some customization of one aspect or another. The config files for it are in /etc/ssh/. And you can start the server by making it's startup script executable:
chmod 755 /etc/rc.d/rc.sshd
and then start it:
/etc/rc.d/rc.sshd start
By making the startup script executable, it should be started by default when you boot the PC from then on. If not, then check rc.inet2 to make sure it's not commented out.
documented on: 12-14-03, DaHammer
if you still can't connect, your workplace firewall may be blocking port 22. A lot of corp. firewalls block that port. You might have to change the default port it listens on. Most corp. firewalls do not block port 53, 80, or 443.
Maybe a little nmap -sS is what you need. I don't know of any better tool to find open ports.
documented on: 12-14-03, timdsmith
As explained in the init (Section 19.2, "init") section, init starts some scripts that handle different runlevels. These scripts perform jobs and change settings that are necessary for a particular runlevel, but they may also start other scripts. Let's look at an example from /etc/rc.d/rc.M, the script that init executes when the system switches to a multi-user runlevel:
Start the sendmail daemon:
if [ -x /etc/rc.d/rc.sendmail ]; then . /etc/rc.d/rc.sendmail start fi
These lines say "execute /etc/rc.d/rc.sendmail start if /etc/rc.d/rc.sendmail is executable". This indicates the simplicity of the Slackware Linux initialization scripts. Different functionality, for instance network services, can be turned on or off, by twiddling the executable flag on their initialization script. If the initialization script is executable, the service will be started, otherwise it will not. Setting file flags is described in Section 8.5.2, "Changing file permission bits", but we will have a look at a quick example how you can enable and disable sendmail.
To start sendmail when the system initializes, execute:
chmod +x /etc/rc.d/rc.sendmail
To disable starting of sendmail when the system initializes, execute:
chmod -x /etc/rc.d/rc.sendmail
Most service-specific initialization scripts accept three parameters to change the state of the service: start, restart and stop. These parameters are pretty much self descriptive. For example, if you would like to restart sendmail, you could execute:
/etc/rc.d/rc.sendmail restart
If the script is not executable, you have to tell the shell that you would like to execute the file with sh. For example:
sh /etc/rc.d/rc.sendmail start
documented on: 2008-05-24
It seems that if I want to turn on a service on next boot, turning on its executable flag is all that I need to do. But, do I also need to make Sxxx & Kxxx symlinks into different run levels as well?
Further, if I want to do my own initialization, does Slackware take rc.local or similar? Or, can I just name my script anything I want?
For built-in slackware rc scripts, yes, simply making sure they are executable will make them run automatically. This is not true for other non-slackware scripts, though. In those cases, if you are using a simple rc script then you need to make sure it is called appropriately. Usually this just means adding a call to /etc/rc.d/rc.local (and maybe /etc/rc.d/rc.local_shutdown if really needed), but sometimes it is better to have the script called at an earlier part in the boot process. In that case you would just modify one of the main init scripts (rc.M, rc.S, rc.K, rc.4).
If you install software that uses SysV init scripts or if you want to make your own (Sxxx & Kxxx symlinks), then you need to make sure the script under /etc/rc.d/init.d is executable with the appropriate symlinks in the runlevel folders. Keep in mind that some software does not by default install the symlinks to the correct runlevel folders. Vmware, for instance, by default install symlinks to /etc/rc.d/rcX.d, where X is 0,2,3,5, and 6. Slackware uses runlevel 4 for graphical login, so you would need to move the scripts from rc5.d to rc4.d or they won't be run when booting in graphical mode.
documented on: 2008-05-25, shadowsnipes
So just to make it abs sure, for my own initialization, I can name my script anything I want, apart from using rc.local or the main init scripts (rc.M, rc.S, rc.K, rc.4), as long as I make proper symlinks in the runlevel folders, and make the script under /etc/rc.d/init.d executable. right?
You shouldn't really need to use /etc/rc.d/init.d/ — you can put your scripts in /etc/rc.d/ directly. The init.d folder is mainly for compatibility with apps designed for other systems. Read the README.functions file in /etc/rc.d/init.d for more information. Generally, you can just add the following lines to /etc/rc.d/rc.local to start an init script that you have either created yourself or that is created when you install an app (keeping in mind that if the app is designed for another system, which is quite rare in my experience but can happen, /etc/rc.d/init.d is a suitable place for init scripts if they're installed by the app itself):
if [ -x /etc/rc.d/rc.scriptname ]; then
/etc/rc.d/rc.scriptname start
fi
(Note that "start" may not be required depending on the init script — you'd have to check it out on a script-by-script basis.) This will check to see if /etc/rc.d/rc.scriptname is executable (and therefore you can disable/enable it on startup simply by changing the executable bit on the file), and if it is, is runs the script (in this case passing the argument "start"). You can add as many init scripts as you want this way and still be able to control them just by setting/unsetting their executable bit (though you really shouldn't need *too* many init scripts).
Also, if you need to start an init script early on during bootup instead of late (rc.local is run last), Pat suggests sneaking it into rc.netdevice (you'll have to create the file, but you won't have to add anything to rc.local, since it is checked for existence in rc.modules* in a default setup). Since rc.modules* is called fairly early during bootup in rc.S, rc.netdevice is a suitable place for init scripts that you want run early, and since rc.netdevice doesn't exist in a default Slackware setup, it won't be over-written if you upgrade anything (UNLIKE rc.S, which *would* be over-written and you'd lose your changes). If you want to use rc.netdevice, create an init script just like you would normally but add the above code into rc.netdevice instead of rc.modules*. See here, from CHANGES_AND_HINTS.TXT:
A trick many people don't know is that if you have modules that you always need loaded in rc.modules, you can 'hide' the modprobe commands in /etc/rc.d/rc.netdevice and nobody will ever be the wiser (you might need to create that file and make it executable).
Note that rc.S checks for the first rc.modules* file it finds in the following order:
rc.modules.local rc.modules-$(uname -r) rc.modules
If you do you the rc.netdevice trick, make sure that
if [ -x /etc/rc.d/rc.netdevice ]; then . /etc/rc.d/rc.netdevice fi
is present in the first rc.modules* file present on your system from the list above.
documented on: 2008-05-25, T3slider
In short, if you install an app that installs SysV style scripts, make sure the main script is under /etc/rc.d/init.d and that the symlinks are in the appropriate runlevel.
However, if you are making your own init script, I recommend doing it the natural Slackware way. If your potential init script basically just executes a command or two then you might as well just put that directly in rc.local (or rc.netdevice if needed earlier). If you need a full init script (or just want it seperate), then the ideal situation is to create an executable /etc/rc.d/rc.name and then call it from one of the slackware init scripts (rc.local, etc). You could really put your init script anywhere you want (even your home directory) and have it called from there; they are just scripts. It's better to be consistent, however, and so I would not recommend you put your init scripts other than the standard place.
T3Slider's advice on using rc.netdevice for calling your init script early on is good, because it does avoid messing with the main init scripts (rc.S, rc.K, rc.M, rc.4). It is safe to modify these main scripts if you need more control, however. They will not get overwritten during an upgrade unless you are careless. I know this from experience because I made a lot of changes to my rc.S and rc.K to change boot behavior depending upon the value of a boot time variable. This would not be possible to do from rc.netdevice. During my upgrade I simply carefully merged my changes.
documented on: 2008-05-26, shadowsnipes
I am going to install either Debian, Arch, or Slackware on a new laptop and was wondering if there is a LiveCD which is close to an actual Slackware 12.0 experience. . .
I want to know what hardware will be immediately recognized and what I am going to have problems with.
Well, a LiveCD isn't really going to be that useful because as soon as you turn a plain distro into a LiveCD you have to make a ton of changes. And then you get a hundred people moaning because you didn't include a userspace driver that runs their hardware, like ndiswrapper. And you have to fix on a kernel version, because of the work to update between them every time there's a kernel release, and then you're stuck with a particular kernel and set of features to go in it.
The easiest way is to see. Personally, in your position, I'd partition a disk into three and try out "real" installs of all three. The chances are you'll choose on look-and-feel rather than capabilities because they are all capable of doing everything you need.
The snd-hda-intel module is actually part of the kernel, so has very little to do with the distro. Newer kernel = newer support for all the chips that use that module. So Slackware may ship with a slightly newer kernel that supports the thing. But if not, no matter what the distro, you'll be upgrading the kernel. You may find Slackware easier to update on the kernel side because it uses a "vanilla" kernel.org kernel. But then Debian etc. will have nice repositories that have updated kernels you can install with a few clicks. It's all pretty much individual to the particular distribution and user.
And ndiswrapper will work fine on Slackware, just the same as every other Linux distro, so long as you use recent versions of everything you need.
People confuse kernel-space, with user-space, with a particular distribution. They are not as dead-set as you think. Just because say, Distro1 didn't support your soundcard, doesn't mean that it can't. And it doesn't mean that Distro2 (where the soundcard works) is better. It just means that it shipped with a slightly different version of the kernel (newer, older, patched, not patched etc.)
The kernel is the same in all the distro's except some projects fix and stabilise on a particular kernel after months of testing, some distro's just ship whatever was most recent at the time of release, some distro's patch it heavily for "user-convenience" and thus you have to re-patch every kernel and wait for patch updates, some leave it alone.
I'd leave out such factors. The only differences to take account of are: What does it ship with? What modifications does it have (i.e. have they included ndiswrapper or do you have to get that yourself)? Does it work the way I want? Does the project update enough for me?
Personally, Slackware is my distro because it updates enough but it's so plain vanilla in its construction that I can install anything and everything in my own time too without having to re-patch or worry about the customisations (the recent Debian SSL debacle shows this quite plainly, too,). I don't care that things can't stabilise for years on end on a stagnant kernel (I like to update my kernel to each -stable release), I don't care that it doesn't come with a million third-party drivers (because my hardware is old and has Open Source drivers for everything), I don't care that it doesn't have a software repository (because I tend to want to make things from scratch anyway).
It's all a matter of personal choice that, in the end, doesn't matter a jot. Just install a bare version of all three and see how they take you. Slackware's only 5Gb or so if you install absolutely EVERYTHING, and on a modern PC that's nothing. Do it in a virtualised container under QEmu if you want to get your decision right first time. I test every new version of Slackware from my workplace's Windows machines using qemu, or I do it from my current Slackware machine using qemu+kqemu which provides a very realistic experience. You don't need to partition or anything - just create a 5Gb file when you set qemu up. If you're going to have to download the ISO's anyway, you can even just mount the ISO directly in Qemu before you waste a DVD-R burning it.
On a side-note, the only Debian-fanatic I've ever met in real life was a royal pain in the backside because he would never update ANYTHING (literally - PHP, MySQL, etc. on a hosting environment plagued by bad PHP scripts) until Debian did it because "they test on stable versions of all the software for years and are therefore more secure". I'm really tempted to give him a ring now. :-)
documented on: 2008-05-19, ledow
Keep in mind that for Slackware it is generally expected that after you install you will need to setup your xorg.conf (manually, or with a program such as xorgconfig or xorgsetup). Also, if your sound doesn't work out-of-box try running alsaconf.
As mentioned, Debian has a very slow release cycle, but is very stable. Slackware has a regular release cycle while maintaining stability. Arch has a rolling release cycle, so there are no real versions for it (just snapshots). Slackware is the only distro of those three that doesn't have dependency resolution in its native package manager. I personally like this, as I don't have to worry about my package manager ever breaking my system. As far as I know, all three have very active forums. Slackware has the smallest *official* repository and debian by far has the biggest. I recommend you look into using slackBuilds.org as a resource for your custom packages for slackware. I've also heard a lot of good things about src2pkg.
I also recommend that you install all three distros if possible. If you do this I recommend that you install their respective bootloader on their root partition and chainload from your main bootloader. That way they are kept separate. This is particularly important for distros that automagically update the bootloader config after a kernel update (I think debian does this).
documented on: 2008-05-19, shadowsnipes
I would like to know if a command exists to remove a package from a directory.
I mean…. I can install packages on a specific directory using :
installpkg -root mydir mypackage.tgz
. . Now I have all the packages in mydir, but there is no:
removepkg -root mydir mypackagename
> removepkg -root mydir mypackagename
your concept is right … your syntax is wrong
ROOT=mydir removepkg mypackagename
tho I see —root or -R appears in a google search for removepkg syntax
documented on: 2007-09-26, by Guest
Check out Zenlive manual on removing packages (See customizing modules). http://www.zenwalk.org/modules/tinycontent/index.php?id=20
documented on: 2007-09-26, by jcsoh
I've been going to Slackware -current at the main site to download the most recent packages of my favorite programs (ktorrent, firefox, thunderbird, etc). I thought this was its purpose actually, to provide the latest packages that were compiled specifically for Slackware. But after perusing the forums a bit I'm starting to get the impression that this is not recommended.
I've not been downloading system files (cups, etc.) just the most recent versions of the software I use. Is there any problem with this?
You are definitely not supposed to run curent packages with the stable release as versions of core components differ. Unpredictable things can happen if you do.
If you plan to stay with 12.0 I would reinstall those packages from 12.0 to be safe.
Current is the development tree and not the same as the stable version, See CURRENT.WARNING in the current directory for more information.
If you want to find any updated packages for Slack 12.0, all you need to do is look in any Slackware mirror. Under the 'slackware-12.0/patches/packages' directory are the latest official packages (product updates, patches, security updates, etc.) that are available for Slack 12.0.
documented on: 04-25-08, regis_n_bits
> I'm currently using the latest generic kernel and kernel module packages out > of Slackware -current (2.6.24.5). The stock kernel (2.6.21.5) does not > support my acpi properly and I haven't yet the time to compile my own. I > made an initrd to load it properly and everything is running fine.
As long as you don't need to compile any modules that are external to the kernel (for example, madwifi, nvidia or ati proprietary drivers, etcetera), then that should be fine. There's a chance that udev wouldn't behave properly with the newer kernel, but that's not very likely in this case, and since it's working fine for you, even less likely
documented on: 04-28-08, rworkman, Robby Workman