Slackware 15 Beta Process Begins

[rogerx]

Slackware really needs to get all packages in binary format, rather than just a few select base packages. Not many people, nowadays, are going to waste time manually compiling every package they routinely use, risking missing depends unless they're academically learning. Debian is not Slackware, so pointing people in the direction of Debian for an all binary packaged sane distribution choice that does not worship a UNIX theology is just weird.

To this rate, it is likely far more desirable instead to use Gentoo, where compiling and depends are handled visibly and automatically, without the risks of many mistakes. The only pitfall of Gentoo, as well as other development arenas nowadays, trying to keep the Gentoo distribution on track from getting sucked into SystemD or other blackhole. Regardless, Gentoo provides a choice between SystemD and OpenRC, and defaults to OpenRC.

Slackware does offer a couple of third party binary package repository sources, however I found significant difficulty using the third party binary package repositories while the repositories also appeared to be significantly out-dated... by year(s) old packages. As if the attempts were seemingly abandoned.

~20 years of using Gentoo here and am in the process of switching to a binary packaged distribution, likely moving to Void Linux. I'm just praying, even though Void Linux is hosted on MS GitHub, MS doesn't buy-out Void Linux or throw a monkey wrench into Void. Eh, when watching for smoke for preventing forest fires, to me, GitHub seems like one huge forest fire already ...

[Mike Frett]

Slackware...the original Linux. The only "true" Linux still available. I wouldn't mind using it again to be honest, nostalgically speaking.

[jacob]

Slackware...the original Linux. The only "true" Linux still available. I wouldn't mind using it again to be honest, nostalgically speaking.

Actually the "original" (or at least first) distro was SLS but it was so primitive and poorly designed that two people decided to fork it and improve upon it. One was Patrick Volkerding with what became Slackware, the other was Ian Murdock with Debian. thus both Slackware and Debian can claim a lineage that goes all the way to the "original" Linux.

On the other hand, since Linus uses Fedora (and I heard him praise SUSE for some usages on at least occasion) we can probably assume that neither SLS nor Slackware nor Debian are the "true" Linux as he envisioned it.

[markus40]

Really a lot of things you can predict when somebody talks about Slackware, BSD and lot of other things

So Slackware miss all the essential things you need when you work with Linux in a cooperation. My Arch install I simply copy from old hardware to new hardware, do a systemd-boot from a USB, and it is up running. For over six years I didn't do a new installation. Still my systems are up to date and running without trouble.
Things I do for fun at home I can directly translate to things I do at my work, because PAM and systemd are essential things to learn and know when you are using Linux more than a hobby at home. The keep it simple stupid argument always comes back, and it pretends the layers a modern Linux runs makes it unstable. This is simply an untrue statement that needs to be corrected were ever possible.

[jacob]

So Slackware miss all the essential things you need when you work with Linux in a cooperation. My Arch install I simply copy from old hardware to new hardware, do a systemd-boot from a USB, and it is up running. For over six years I didn't do a new installation. Still my systems are up to date and running without trouble.
Things I do for fun at home I can directly translate to things I do at my work, because PAM and systemd are essential things to learn and know when you are using Linux more than a hobby at home. The keep it simple stupid argument always comes back, and it pretends the layers a modern Linux runs makes it unstable. This is simply an untrue statement that needs to be corrected were ever possible.

I think it's simply a very different understanding of simplicity. There are two schools of thought. There are those who believe that software implementation should be simple and transparent, which often means that the user is exposed to the full complexity of the problem he/she is dealing with. Taken to the extreme, this is the "suckless" approach. On the other hand, there are those who believe that the software's interfaces (including the user interface and workflows) should be simple, which typically means that the software is expected to absorb the complexity of the problem. This is the systemd/dbus/GNOME approach.

[markus40]

I think it's simply a very different understanding of simplicity. There are two schools of thought. There are those who believe that software implementation should be simple and transparent, which often means that the user is exposed to the full complexity of the problem he/she is dealing with. Taken to the extreme, this is the "suckless" approach. On the other hand, there are those who believe that the software's interfaces (including the user interface and workflows) should be simple, which typically means that the software is expected to absorb the complexity of the problem. This is the systemd/dbus/GNOME approach.

I'm not disagreeing with you. And yes, I see benefits in the simple and transparent approach to learn how things work. In the beginning, or even when you face a new thing that is buried in layers of other functionality. Heck I do it now with new things, I encounter, not by running Slackware. But to strip the functionality, I don't understand, to the bare minimum and play with it. Even the stripping down needs a lot of research and thus learning. With this approach, you'll find tools and application you can later use for debugging. Last year I did this with SOAP. I have build client and servers with python and PHP, found SOAP UI, which I use now for debugging, etc. The funny thing is the 'purist' will not see what I was saying above, but stops reading at PHP and scoffs at it. Missing the point. The arguments I always hear when there is talk about Slackware (or BSD) about the stability of that approach against 'modern' Linux is the thing I have troubles with. It is not true. It is a trope, like Buddhist monks in movie and TV-shows.

I don't attack Slackware or BSD. Each has its merits. Not for me, but enough other people to make it relevant. I got problems with the Holier-than-thou
card which is always played. As if playing the Slackware or BSD card makes you somebody who knows what he is talking about. The quick shortcut to 'graybeardism'. 'Debian', to a lesser degree has the same problem. Gentoo and Arch, which I use at home and CentOS/RedHat at work, have totally other crowds who see it as a shortcut to some other trope.

[higuita]

I guess we'll just agree to disagree about that. I really don't see the point of learning about old-style /bin/init on a systemd distro

All depends of what you want to learn! i'm not saying everyone should use slackware and learn everything, a linux end user will be fine with ubuntu... but a future a linux sysadmin will need to learn much more other than clicking with the mouse. Just take a look to containers, very few use systemd, few even use any special init, but few do need to start several services and do need some init. What is it job, what features, how to use it are a requirement for any good sysadmin or devops. Again, most people do not need this, how most people do not need to learn how to work with windows powershell or registry.

The point I was trying to make is that most people don't actually need to manually configure network interfaces or use ss or they can worry about it on the one occasion when they actually need it. Learning GNU coreutils is not a goal by itself, people's goal is to get productive stuff done. And, where to draw the line? If you say that people should start by learning to use the "ip" command manually (or even the old "ifconfig"...) then why stay at the shell level? Why not start with learning the syscall, or rather the "sysenter" assembly instruction etc...?

Again, you are thinking as a end-user, where i'm talking in people that want to LEARN, either advance users and developers, devops, sysadmins. How many normal users used the net or ipconfig command in windows? But good windows sysadmins for sure already used then.

[higuita]

Slackware really needs to get all packages in binary format, rather than just a few select base packages. Not many people, nowadays, are going to waste time manually compiling every package they routinely use, risking missing depends unless they're academically learning.

This is really the major road block for slackware being more widely used, many people do not want to compile or used older packages (that still work fine, notice). That is why people migrate to debian (many packages, also may be older version) or arch/ubuntu (many packages, more recent versions). We do have slackbuilds, that with sbopkg, you can compile packages with ease. Also the main alienbob repo have most packages already compiled... but of course, this do not covers everything.
There is also the way to convert debian packages (or rpm) to tgz, but of course, not all packages work and if using too many packages, then you should really use debian instead

i do have other distros installed and when i really need to test something, either reboot or simply mount that distro, copy the X11 socket and cookie and chroot to it... it allows me to test some software that may be too troublesome to compile by hand... i know that some people also use docker packages to do that. But this is mostly for special tasks, i really do not miss any software on my machine that i don't find in slackware or in alienbob repos

[higuita]

So Slackware miss all the essential things you need when you work with Linux in a cooperation. My Arch install I simply copy from old hardware to new hardware, do a systemd-boot from a USB, and it is up running. For over six years I didn't do a new installation. Still my systems are up to date and running without trouble.

nonsense! slackware is probably one of the easiest distros for switching hardware

ls -ld /mnt
drwxr-xr-x 1 root root 578 set 26 2006 /mnt

So my slackware is installed since 2006 and been updating since without any problem... and this was when i finally upgraded my 486 machine, as my previous main disk had a slackware install since around 1998, but i decided for a clean install
Upgrading hardware or even changing complete machines, i didn't even to execute anything, grub and the kernel worked fine. Most slackware installs do not even use initramfs, so everything really works as long as the kernel knows about the hardware

The only major upgrade that needed more work was the 32bit to 64bit upgrade, but the flexibility of the slackware package manager allowed me to do it without problems.
The switch from MBR to EFI was done when i upgraded to a SSD by correctly partition, rsync the root filesystem and configured fstab, efi and grub and reboot

My old 486 had a IDE removable disk and i would unplug it, carry it to my parents house and plug on their k6-2 computer and keep using the same linux in both places without any other change.

[rogerx]

So my slackware is installed since 2006 and been updating since without any problem... and this was when i finally upgraded my 486 machine, as my previous main disk had a slackware install since around 1998 ..

I knew there were more out there like myself!

If it still works, why throw it into the garbage or replace it?

One neat thing I just realized with static releases and rolling updates, the troubles of integrating newer software layouts. With a release model like Slackware, the integration of newer software layouts is minimized and likely less troublesome. However, I have not used Slackware very long at all. I have only used Gentoo for a very long time, and after several years, started noticing redundant software package breaks and the increasing old unused left behind files. Within recent years, I was starting to think this problem was unavoidable until just now.

Slackware might be the only platform available for platforms or CPU's not having SSE2 instruction set. (eg. Rust programming language requires SSE2, and seems to be fast becoming a package depend for every popular software application, such as every Internet browser.) If Slackware 15.0 still supports non-SSE2 platforms, I might use it on my older platforms. If that fails, then there's always FreeBSD, but who know's how long until Rust completely invades FreeBSD.