SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I don't run stable, I run Slackware64-current. However, I suspect that there are some trusty old servers out there that are running 14.1.
I agree they might be trusty, but it has however far more to do with the environment they run in — for example, strictly on a LAN – than with how up-to-date they are. Beyond that, "so far so good" is not a very strong security policy.
NetBSD uses individual scripts for controlling services, similar to what System V does, but without runlevels. This chapter is an overview of the rc.d system and its configuration.
If you do not known yet, the BSDs has one single runlevel, contrary to Slackware, which like any other Linux OS, has 6 (six).
And how applies to Slackware the rc.order as dependencies resolution for init scripts?
rcorder is designed to print out a dependency ordering of a set of inter-
dependent files. Typically it is used to find an execution sequence for
a set of shell scripts in which certain files must be executed before
others.
Each file passed to rcorder should be annotated with special lines (which
look like comments to the shell) which indicate the dependencies the
files have upon certain points in the sequence, known as ``conditions'',
and which indicate, for each file, which ``conditions'' may be expected
to be filled by that file.
Within each file, a block containing a series of ``REQUIRE'',
``PROVIDE'', ``BEFORE'' and ``KEYWORD'' lines should appear. The format
of the lines is rigid. Each line must begin with a single ``#'', fol-
lowed by a single space, followed by ``PROVIDE:'', ``REQUIRE:'',
``BEFORE:'', or ``KEYWORD:''. No deviation is permitted. Each depen-
dency line is then followed by a series of conditions, separated by
whitespace. Multiple ``PROVIDE'', ``REQUIRE'', ``BEFORE'' and
``KEYWORD'' lines may appear, but all such lines must appear in a
sequence without any intervening lines, as once a line that does not fol-
low the format is reached, parsing stops.
If you do not known yet, the BSDs uses dependency ordering for their init scripts, contrary to Slackware where the init scripts order is hard coded on the main scripts.
I tell you those things as someone who used for many years the NetBSD and FreeBSD.
They have nothing to do with the Slackware init system more than they have with SysV init.
At least today, the Slackware is not that BSD-like, as the legends says.
Before to ask rhetorically why I use exclusively Slackware today, permit me to explain that just happened.
Almost a year ago, a power outrage (while a tempest) fried all electronic devices from my house. Starting from computers ending with the TVs and fridge. I have bought 4 computers, for my wife and my 3 boys (I have 16 years old triplets) and so on. Up to brand new air conditioners, fridge and TVs.
When I finished this shopping spree, I had moneys enough to buy for myself a SD-card. Which was pure luck, as I had this mini-PC which I use today, on those times being in storage. Slackware happened to be more versatile as for my experience, to be installed quickly on this SD-card.
And on this almost one year, I have discovered that I do not need more, for myself, than a Linux OS on SD-card. Just for browsing the Internet, nothing more.
I am not an open-source activist or systemd hatter. Neither I am a Linux Guru.
Last edited by ZhaoLin1457; 03-10-2021 at 05:44 AM.
I see the Slackware init process as intermediate between BSD and SysV. Yes, there are nominally 6 levels because it's Linux, but they aren't much used in practice. In a proper sysV initialisation, clusters of symbolic links in the /etc/rc.d/rc.N directories launch or kill the scripts required for level N. Slackware has those directories, in case packages want to put stuff into them, but they aren't normally used. Instead you have a single script for system initialisation, another for a multiuser boot and another for shutdown/reboot. That looks like a BSD to me.
What NetBSD does reminds me very much of the old-style Debian. When Debian used sysVinit, it had this thing called "concurrent makefile booting" which worked just like that.
I see the Slackware init process as intermediate between BSD and SysV. Yes, there are nominally 6 levels because it's Linux, but they aren't much used in practice. In a proper sysV initialisation, clusters of symbolic links in the /etc/rc.d/rc.N directories launch or kill the scripts required for level N. Slackware has those directories, in case packages want to put stuff into them, but they aren't normally used. Instead you have a single script for system initialisation, another for a multiuser boot and another for shutdown/reboot. That looks like a BSD to me.
What NetBSD does looks very much like old-style Debian to me. When Debian used sysVinit, it had this thing called "concurrent makefile booting" which worked just like that.
All BSDs uses rc.order and this dependency order for the init scripts, it is not specific for NetBSD.
The Slackware lacks this feature, having the order hardcoded on the main scripts, like I said.
And if you wonder how looks a BSD rc script, it's like this:
So, this example script would be something like /etc/rc.d/rc.gpm, but please tell me: what it have in common with Slackware and its init scripts?
As someone who used for years two BSD distributions, I believe that Slackware init system is just a flavor of SysV init, which has nothing in common with the BSDs and their init scripts.
Last edited by ZhaoLin1457; 03-10-2021 at 06:10 AM.
As someone who used for years two BSD distributions, I believe that Slackware init system is just a flavor of SysV init, which has nothing in common with the BSDs and their init scripts.
It's not even that. Slackware's init is quite unique. There are no others like it. You are correct in your statements. It's nothing like any of the BSDs.
In fact, people who don't know an awful lot about Linux can do a full Slackware install and they'll have a good-tempered stable system that will do everything they want and never throw a tantrum during an update (as Debian distros sometimes do). What's wrong with that?
Furthermore, it has some of the best commentary/hints/pointers exactly where you need them in the config files. You don't get that with many other distros.
On that front, Slackware is easily the most newb-friendly. Try explaining systemd unit files to a Linux newbie, versus telling them to add something to /etc/rc.d/rc.local.
On that front, Slackware is easily the most newb-friendly. Try explaining systemd unit files to a Linux newbie, versus telling them to add something to /etc/rc.d/rc.local.
I don't think the installer is particularly newbie-friendly. No graphics and you have to do your own partitioning. Or is that different if you install from DVD?
Also I don't think most newbies feel happy about being told to edit configuration files by hand. It's not the way they've been brought up. Remember most of our generation are familiar with command line because they have used it in office work, or administering servers, or else they've used DOS on home systems.
Actually I quite like the systemd unit files (shock! horror!). I find them easy to understand and well documented. There's a lot of things about systemd that I hate, but the way it's configured isn't one of them. The problem with init scripts is that they have to be very complex to deal reliably with all the variation between systems, and trying to edit them when you don't fully understand the logic is really difficult. I must admit that I don't meddle with them, and I do know a bit about bash scripting.
Actually I quite like the systemd unit files (shock! horror!). I find them easy to understand and well documented. There's a lot of things about systemd that I hate, but the way it's configured isn't one of them. The problem with init scripts is that they have to be very complex to deal reliably with all the variation between systems, and trying to edit them when you don't fully understand the logic is really difficult. I must admit that I don't meddle with them, and I do know a bit about bash scripting.
It's true with things like OpenRC, about which I understand someone could say "I can fix it!" — whatever you might think about the fix — but far less with Slackware. Its init is maybe not as flexible as you could expect, but it has the great quality of clarity.
I don't think the installer is particularly newbie-friendly. No graphics and you have to do your own partitioning. Or is that different if you install from DVD?
AFAIK with the exception of the LiveSlak "usb2hdd" script, any invocation of "setup" from any media results in exactly the same process. I actually prefer partitioning ahead of time outside any installer. That way I can label the partitions I intend to use and make note of exactly where I want everything to go. It seems an important lesson in the Six Ps Process.
Recently I've seen some newbies complain that they feel lost outside of a typical GUI installer, but I must confess my feelings are polar opposite. All I need to know is what is proposed to install and where and that information is often obscured or even lacking in some GUI installers. I find the Slackware installer to be clear and simple.
I actually prefer partitioning ahead of time outside any installer. That way I can label the partitions I intend to use and make note of exactly where I want everything to go. It seems an important lesson in the Six Ps Process.
Recently I've seen some newbies complain that they feel lost outside of a typical GUI installer, but I must confess my feelings are polar opposite. All I need to know is what is proposed to install and where and that information is often obscured or even lacking in some GUI installers. I find the Slackware installer to be clear and simple.
I think a lot of Slackware users feel like that. But I don't expect most Linux newbies would understand it at all. Not after a lifetime of using Windows. Like I said, it's a generational thing.
On the installer, I think it's an age thing. People who were kids in the millenium only use ½ of linux - the GUI. People fromn before that are comfortable with the other ½. It's not linux that's at issue at all. Give them Dos, and they'd want to start windows. I was very much a tty console jockey until I increased the font size. Now I prefer the gui terminals for the longer history.
Now I prefer the gui terminals for the longer history.
You just wait till you try the new consoles! They don't scroll back at all. The new kernels don't support that any more. So it's not a question of longer history, it's a question of having any history at all.
I'm really annoyed about this. It's not Pat's fault obviously, but I'm annoyed with the kernel people. This was part of the Linux way of working and they suddenly pulled the rug out from under our feet.
Are you guys talking about bash history? If so I'm happy to report that Konsole is unchanged for me with up-to-the-day Current and Plasma5. My Up and Dowen arrows still scroll through a huge archive of used commands. I'd just like an easy way to eliminate duplication.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.