I just create a script in /etc/rc.d/rc.local_shutdown with
Deletes hidden files in /tmp, too

I mount /tmp with tmpfs.

It would be nice if it was just a little more obvious. I couldn't remember seeing any reference to the helper script in the DVD docs. I found it in the CRYPT and LVM docs, which I've never read because I'm not using either of them. Everyone using -generic needs to run mkinitrd though, and there's no mention of the script in the README.initrd. It would be helpful to have the section "A mkinitrd helper script" from README_CRYPT at the end of README.initrd.

Hi,

What issues? Crash-prone? No problem here. I would suspect something wrong with your install or system. I don't see major issues or problems here on LQ. How about being a bit more specific?

BTW, you should be aware of security issues by rolling back that far.
:hattip:

I don't think it is the install/system. I think it is just a simple matter of an extension or plugin that is causing the issue.

+1. I've had zero issues with FF, of course I only use the default plugins + flash.

One of my favorite lines ever:

Hi,

I was speaking in general about the install. It could be the package or as you said a plugin/extension for the app. That still is part of the install from my point of view. His solution was to roll pack the package but that will open security issues. In my book a big step backwards.

It would be better if the problem was diagnosed properly then actions could be performed to lead to a solution instead of ignoring a problem by roll back.

:hattip:

Thanks for the comments on the /tmp directory. I looked at using tmpfs and found this as the suggested fstab entry: from the Gentoo forums. For now, I'm going with the /etc/rc.d/rc.local_shutdown approach. This doesn't use memory and my computers are low-power (intel atom and via C7) types and I think I need all my ram. I also appreciate reading about tagfiles for custom installation. Well, I guess now I will have to withdraw my complaint. Slackware rocks!

Lets' just, "Install Everything" - or is that unsafe?
 

Yes, there is a LOT of history for you to catch up on, but only if you feel the need, as Slackware is working well for you and you've now stumbled upon arguably the best all-around distro for running servers and workstations that there is.

Heck, even for running a NAS, AFAIC, although things like FreeNAS are purpose built rollies that perform one single role well.

When Patrick wrestled with the need for a UNIX, and chose to cleanup SLS in order to obtain a flavor of UNIX that would meet his needs, and then started getting hammered with requests by others to make his stable spin available to them too (um... we had JOLIX, XENIX, Coherent, MTM, and SLS prior to this - unless of course you had a VAX taking up space in your pool room), he reluctantly and unbeknownst to him at the time, gave birth to what is now the oldest Linux Distro still in existence and actively maintained.

The installation philosophy was simple, and remains almost the same to this day. back then, there was a great emphasis on NFS installs, but all those little alphabetically organized software sets that you see actually correlate to floppy disk image sets (Yes, we actually used to pile them up much like we did the decks of 80 column punch cards less than a decade prior to this).

It is still the same way (much in the spirit that most of us actually use tar for backups regardless of what else we also use, and irrespective of the fact that you would be hard-pressed to find a refrigerator-sized tape drive that is operational nowadays).

You simply make a few advanced determinations of your needs (since you only have a 40Meg HDD LOL! - NOT!), and choose those software sets.

Since the majority of folks wanting to get on the UNIX bandwagon from DOS based systems were still trying to get their heads around the difference between A:\, C:\, and /; offering an "Install Everything [Under the Sunsite.edu] was a simple ingress for these n00bs (Now, mostly the 'gurus' that you're discoursing with).

Sadly, space was at a premium back then, and many of us were forced into actually choosing our software sets anyway (again, the way you were 'supposed' to do it anyway). The, "Install Everything" was simply beyond the capabilities of most of the 386 boxes we could scrounge from the dung heap - Oh, we formatted our HDDs RLL and begged and spinwrited dead SCSI drives from our MIS departments in order to achieve the space for such a simple install, but most of the time we just got used to saying, "This box needs to do x, y, and z, so I'm only going to need the following particular floppy disk sets..."

Here's a post I made recently, just a social commentary really, about that very thing, and if you read through the gleanings of that thread you'll note the following passage by me:

The full post for that topic thread is here: http://www.linuxquestions.org/questi...5/#post3992843

So, perhaps it's more accurate for you to state, @2handband, that although certainly convenient, you can hardly wait until you are more comfortable with the ins and outs of the particular Slackware Software Sets so you don't have to include things like X, and Games, in your typical default installations.

I know that someone above suggested you simply install everything and then use the package management system to tag and remove everything you don't want, but I wouldn't personally advocate that approach.

Slackware, although it will, wasn't designed to be installed with that methodology in mind, it was designed to be installed, and then go about "enabling" and "customizing" all of the services, daemons, profiles, init-scripts, etc., for your particular application or enterprise - eventually yielding EXACTLY what you want.

Redhat is just the opposite - you install it and then begin to disable everything that shouldn't have been enabled, IMNSHO. Sure, at one time, I thought Redhat and RPM based distros were the kewlest thing in the Linux world, almost as kewl as the BSD Ports system, but as time wore on and I found myself in rpm_dependency_hell at rpmfind.net, and ultimately having to make my own RPMs for security patched daemons running on versions of Redhat that were no longer supported by anyone but myself, I eventually left the Redhat camp for good at the end of the life cycle for RH 5.2 and focused almost entirely upon Slackware again.

Setting up a [secure] box took much less time w/Slackware, and even if I did an, "Install Everything", I was still presented with the scenario of presenting a forward facing machine with one aspect of software at at time, opening it up little by little, adding services one at a time, and knowing that the only security holes presented were the ones I introduced.

Conversely, following a Redhat install (even to this day), it is my opinion that one should be running an adequate battery of port scans and other penetration assessments before allowing an RPM based box to be forward facing, disabling the obvious holes and then working until you are fairly comfortable the box is secure. This takes much more time and effort than the scenario in the paragraph above, and yet you're still faced with customizing the machine following all of that.

Once you know the Slackware way, you indeed know the BSD UNIX way, and you know how things are going to be installed and where, as well as what is going to be changed, especially if you peruse your SlackBuilds, which you can change if you prefer something else.

If you YUM it, or even 'rpm -ivh pkg_name' it, you are at the mercy of whomever it was that decided it was best for their particular installation - perhaps overwriting things you didn't want overwritten, perhaps breaking existing things on your system wrt dependencies on PARTICULAR libs, and perhaps even introducing major security issues.

If you must, Slackware does indeed support RPMs natively, and also has included, rpm2tgz, although YMMV.

And, when you can't find a SlackBuild, you can always just compile and install by hand or (and I'll prolly get flamed for this) get a package from the SalixOS package repository.

So yes, I'll agree with you in principal that it's a big No-No to do an, "Install Everything", in general, and with most distros, but wrt Slackware, it really isn't what it appears - all you've really done is just install the files so you can enable capabilities, instead of having to disable (hopefully) everything that presents a security hole.

Now @2handband, don't come back to me and say it's because you're limited on your space ;)

Kindest regards,

.

The only plugins I've installed are flash and kaffeine-mozilla, both from the slackbuilds.org scripts.

Mostly it likes to crash when I try to listen to mpeg audio. Every time I try to listen to mpeg audio. It simply closes all the Firefox windows that I have open at the moment. Mpeg works fine with Konqueror. There's also been one random freeze-up; Firefox simply hung up and wouldn't do anything. I don't know what caused it; I multi-task so much that it can be really hard for me to pinpoint this stuff. I'll probably have two or three browser windows open at one time, all of them chock-full of tabs.

Well then I think you just found your problem. It is kaffeine-mozilla. Try simply downloading your mpeg audio to your disk and open it with either regular kaffeine, or vlc. It is a plugin issue, not a Firefox 3.6 issue.

Is something wrong with kaffeine-mozilla?

Well obviously, since you say you are playing your media through that particular plugin which seems to be causing the trouble. To confirm my suspicion, why not try my advice and play your files through a regular player, such as kaffeine itself, or vlc, or xmms, or whatever other player that supports mpeg audio, and see if Firefox still crashes.

In short, yes I guess you can say that there is something wrong with that particular plugin, in which case you should perhaps report it as a bug to the original author of the plugin, (include logs).

I can't say that there's anything I don't like about Slackware. I cut my Linux teeth on Slackware and using it is like going home.

If I had a wish list, it would include a

1. GUI front end for iptables.

2. Xine, no Gxine.