It seems a very clumsy solution, not really solid. It's better than nothing, I suppose.

When I started using Linux, I once discovered I needed to handle encrypted filesystems in a semi-automatic fashion. I just built a script than, when double-clicked on, would prompt for a password for every filesystem, build a numbered folder for each and mount them all in order. It was cool for me, because I felt like an unstoppable teenager shell programmer... but even that approach is damned clumsy.

I suppose it will be of not help, but I am worried too about the future of FOSS operating systems.

Firstly, I see the quality of most Linux distributions quickly degrading. Quality control is less and less effective with every distribution release. That's not a problem for bleeding-edge distributions, as they are not supposed to be solid after all, but nowadays I don't really trust even Debian. Slackware is the last useful distribution of my list (and no, I am not LFSing unless for fun). I suppose it is my duty to contribute to mend this, but I got tired of sending bug reports which were answered "We'll fix that later" and were never attended, even when upstream HAD fixed them.

Secondly, userspace software is getting more and more complex for no gain. I read an article wrote by a kernel hacker in which he declared that old (as in "Amiga") software booted faster and performed better in neolithic hardware than recent OSes on factory new computers. "I feel the need to cry!", he said (or something alike). Apps are getting built on abstraction layers built on abstraction layers which are built on other layers... each layer having it's bugs and issues. Now, desktop environment themselves are developing platforms (?!).

Third, even BSDs are not safe at all, because they just can keep their core basesystems clear. Most user applications are the same as in Linux, and have the same issues. At least, BSD guys seem to have some sane ideas (just look at OpenBSD, where it is not unusual to hear the maintainers shout "If upstream keeps producing crap, we will just take the last usable source and patch the hell of it until the four riders scorch the earth!") Plus, since systemd was started, and (U)EFI is threatening to become mainstream, I have not being able to figure a bright future for the BSDs.

The reason I use Slackware is because it is good buying time for us, keeping the obstacles out of the road as long as possible until there is no way to avoid them. And because they keep some kind of quality control which is not to be expected from others.

On a more happy tone, I could say that impending doom is what has leaded me to give the BSDs a try. They are very nice systems: if you haven't, you could try them before the forces of evil infiltrated in the FOSS world find a way to take them out :-)

4 members found this post helpful.

I suggest we try to stay on topic as much as possible, the goal of this thread being to report issues in RC4 that {c,sh}ould be closed before Slackware 14 be released.

Just put down a fresh install of RC4 on my netbook. Only been running a few hours so far but no problems at the moment. Just been running XFCE with Opera and Skype so far

BlackRider, you should read the post "Slackware from Scratch(?)" I posted here in regards to using a BSD style audit system for Slackware and the ability to recompile Slackware's base and base development system from scratch if needed, and maybe even other packages as well.

One problem Linux seems to have, that systems like LFS and Slackware have managed to avoid, is some level of constant instability and unrealiability that forces people to keep distro-hopping.

I hopped through about every major big-brand Linux until I hit Slackware. Red Hat, SuSE, Mandrake, Ubuntu... yes I use Xubuntu on my laptop still, but yes even I don't trust it like I do with Slackware as far as stability goes.

I dare say this, but if ANYTHING ever happened to Slackware, I know first hand where I'm headed which is LFS or FreeBSD... and I love FreeBSD, and so far Slackware has been the only Linux to keep bringing me back to Linux fulltime as far as distros go.

I've put RC4 through few paces over the last few days. It's been perfectly stable for what I've done with it which is essentially to do a clean install, copy over a huge directory, verify it, sort it, and clean it up. The only thing I've experienced that seems weird has been a delay in responsiveness (click the mouse and firefox doesn't jump) a few times, but those were while I was doing the md5's for about 20,000 files over 180GB or comparing those files looking for duplicates against filename and md5 hashes and that may or may not be exacerbated by the xfs filesystem I'm testing out as well.

In general RC4 seems to be the best OTB Slackware version I've used as far as speed and an over all "polished" feel goes, but I've only been using it since 13.0, so you may feel differently about Slackware 2.01 or something! lol

Thanks to Mr. Volkerding for adding rp-pppoe to testing/.

I think i found another minor issue with the ca-certificates package. I searched the slackware-forum/thread for it but couldn't find anything about it. If this was discussed already, just ignore it.

Steps to reproduce:
*Fresh install of slackware32-current or slackware64-current.
*Try to rebuild glib-networking with the Slackbuild from the current-tree (l-series).
*The configure script will complain about not finding the ca-certificats.crt file.
This file (ca-certificates.crt) should be created by the ca-certificates-package from within the doinst.sh script but there is no *.crt file in /etc/ssl/certs.
If i run the command from the doinst.sh script manually i get the ca-certificates.crt file:
If you run the glib-networking.Slackbuild again everything is fine because there is now a ca-certificates.crt in /etc/ssl/certs.

The command inside the doinst.sh script of ca-cartificates-packages works well if you re-install the binary package so it looks like the update-ca-certs command does not get executed during setup but when re-install the package.

I replaced my work install of Slackware 13.37 with Slackware64 14.0RC4. Since I also changed architecture I had to do a full reinstall. No major problems other than a small number of SlackBuilds from SlackBuilds.org failing. Though luckily only one of them was a critical (for me) package that I use regularly. That one I compiled under a quick Slackware64 13.37 chroot I setup and the resultant package seemed to work just fine under 14.0RC4. I intend to look at the the reasons for the handful of failing builds when I get a spare moment though I strongly suspect just a few small tweaks to the build scripts are needed. Also 3 of the fails were simply due to problems with sbopkg downloading the source rather than changes between 13.37 and 14.0RC4. I should also stress that the vast majority of packages built without any problems. All in all I'm very happy with 14.0RC4 in my limited usage thus far.

Humbly replying to myself and anyone else who ran into trouble automounting USB devices and CDROM/DVD's in XFCE only RC4 installs.

Problem solved. Due to the new udisks2 and gvfs setup in Slackware. For GTK2 desktop managers like XFCE, removable devices may need an additional identifier in their respective fstab entries. In this case for an XFCE only install using XDM, or any GTK2 login manager, I added "comment=x-gvfs-show" to fstab for my USB stick entry and CDROM. Shown in the following example:

Lo and behold. Inserted devices appeared on desktop and Thunar. Ready for mounting. And when selecting automount in Thunar. Mounted devices appeared.

3 members found this post helpful.

I never had those problems, I still have an issue with SD cards, the only way to see them or mount automatically is to have the card in, and reboot...then the SD Card is found / seen only after rebooting.

I'm sure there is a simple fix, but that seems to complicated for this simple man : )

hmm :-)
/var/log/packages/intel-gpu-tools-1.2-i486-1
files are put in /usr/bin but everything needs to have root to run?
why not place it in /usr/sbin directly?

I would appreciate information of what triggers /lib/udev/rules.d/75-cd-aliases-generator.rules.

I have two Slackware 14 RC4 environments. The rule set is executing correctly in one system to generate a full slew of /dev/dvd* sym links, but not in the other. There I never get any /dev/dvd* sym links. I reinstalled the udev package and rebooted. No sym links.

That's the upstream default directory, so you might inquire with them. Other distributions have not moved the tools from /usr/bin, and moving them could possibly break something external that calls them (though I'm not aware of examples off the top of my head).

I'm curious if the two environments you're describing are on seperate hardware. And if the misbehaving /dev/dvd system is using a 64 bit install *and* is using both a sata harddrive and ide cdrom/dvd drive(s)? And finally, is the motherboard less than five years old?

If all of this is the case. After every bootup, does issuing the terminal lsscsi command show the drives, particularly the CD/DVD drive, being inconsistently detected?

Ignore my question if that's not the case.

Different partitions on different SATA II drives. No IDE drives. Same motherboard: Asus M2NPV-VM. No problems with lsscsi.

Both the behaving system and misbehaving system are 64-bit, although now that I think about this, there is a third Slackware 14 setup but 32-bit, and that environment does not create the sym links.

I just now noticed in the misbehaving systems that /etc/udev/rules.d/70-persistent-cd.rules is not being generated. That is the rule set that actually creates the sym links. I need to figure out what creates that rule set.