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.

1) Updating a multi-lib install is a pain, as you have to find out what 32-bit packages need updating and run the updated packages through the conversion script before installing them.

2) A stripped-down KDE version like the kde-base package in Gentoo. It doesn't install Akonadi, uses 150-200 meg of RAM, and isn't lacking any features that I need. I think people would appreciate less bloat; I've seen a lot of people going to XFCE for this very reason.

3) I understand not everyone is a fan of 64-bit multilib, but it would be nice to provide this as an option in the installer. I always come across something that needs 32-bit compatibility like flash, acroread, wine, and several games. Also, creating an environment variable that tells Slackbuilds that you have a multi-lib install would be nice: then I wouldn't get a pure 64-bit Nvidia driver install and wonder why my 32-bit game doesn't work.

To the guy recommending Arch: I thought about trying it until I read that every package is bleeding edge, so you end up being a beta tester of sorts. People on various forums seem to dread updating their Arch systems as they tend to break. For me, I would prefer a distro maintainer to pick the latest stable versions of packages for me so I have no problems with updates breaking my system. I also prefer adding packages to a base install instead of getting everything like a default Slackware install gives you, but I don't see it as a big deal. You can always remove packages, and if you don't like the stock mplayer build for example you can always tweak the Slackbuild and replace it.

Only for not spelling "probably" properly :)

samac

Instead, I appreciate that Slackware packages be not stripped down. For instance Slackware packages for mozilla-firefox do include the internal xulrunner engine ; some other distribution's packages do not. And I appreciate that the -dev portion of applications, whenever applicable, be included as well.

If you want to get rid of akonadi, it's just a removepkg away.

And still you can make you own stripped down package: just edit the provided slackbuild, tune the configure options and run it again.

Hey, is it possible to recompile kde-4.4.3 without akonadi? It gives an error upon every boot, so that i have to launch kmail twice, because closing akonadi error message also closes kmail at first launch.

At the same time without akonadi installed kmail won't even start.

This just makes it more time-consuming (and annoying) to have to compile/install xulrunner if you want to install other gecko browsers (like conkeror). This is one of the few instances that I would prefer package splitting.

+1 on that. I have requested this from Pat, and i bet other people have too.
His reply was that he wont be doing that cause 32bit ships the official binaries from Mozilla.

I would also like a split seamonkey as well (seperate nss & nspr) but last time i requested this seamonkey-solibs was born, so i am reluctant to request such things again. :)

If only slackware also send optimized distros (official if possible) to specific archs and not only i486 then it will also be a +. There's a way to recompile all the packages in Slack but that will take time. More time compared to Gentoo since you still have to think about the dependencies.

I couldn't find any information about Conqueror (guess you didn't mean konqueror, as it uses khtml, not gecko, as its rendering engine). Could you provide an URL or pointer ?

Anyhow a slackbuild for xulrunner is available @ slackbuilds.org.

The inconvenience of stripping xulrunner from firefox is that then you can't run an application for xulrunner with "firefox -app appname", which is possible since firefox 3 if it is shipped complete.

Conkeror, not Conqueror. ;)

Thanks to sahko and T3slider for correcting my typo.

Out of curiosity I just downloaded a snapshot of conkeror in my $HOME, untarred it and launched it that way:It worked, of course because the Slackware package for Firefox does include an internal xulrunner engine, as it should ;)

You actually have 2 xulrunners cause seamonkey includes its own version as well.
Building a seperate xulrunner package would mean both apps would use the same engine.

I will soon have 3 xulrunners then, as I plan to install a standalone one ;)

I don't see that as an inconvenience, as I have enough space on disk.

I stand by my opinion: I prefer not split packages, even at the expense of some more space needed on disk.

For instance I like the package for vlc provided by alienBOB, as it includes all the needed dependencies. I don't care that some be already available in my system, I can live with duplicates.

The lesson with VLC (and other pre-packaged multimedia software) is that there are strict dependencies on the versions of supporting libraries. The *ubuntu people usually learn this the hard way; when they upgrade their ffmpeg or x264 packages, several other programs will break - like VLC. Their forums are full of complaints about this dependency hell.

Therefore, adding the support libraries statically to the main VLC package has the advantage that the situation on-disk may change (you add, remove or update your multimedia libraries at will) but the Slackware VLC package is immune to those changes and will continue to function. You'll get a fat package (if you look at the build script, actually over 40 different source tarballs are being used) but I don't care about that.

Handbrake (the video transcoder) adds its support libraries in a similar way (the developers want to control exactly which software and patches their program is using - saves time on support questions).

There is a big thread on ubuntuforums.org about building VLC development snapshots - the procedure is based on how my SlackBuild script adds static libraries... because people are affected negatively by the "medibuntu" packaging disaster. Very funny to read, and confirmation that I follow the right path.

Eric

You're right; uninstalling kaffeine-mozilla solved the stability issue. I'll file a bug report, but in the meantime does somebody know of an mpeg plugin for Firefox that works?

Couldn't you just stick that same code into the rc.6 script?

(Somehow I've missed this thread for 4 months?!?) The thing that I most dislike about Slackware is that it continues to be a long term paradox. Each release seems like the Greatest Thing Ever (sometimes even to the point of where I say it's "perfect") but then the next release comes out and it's even better... better than perfect?!? Now I have the strange situation of having to answer the question, "So, how's the new release of Slackware?" with "Well, not as good as the next one will be, but still... absolutely perfect." Darn it all to heck, Slack team, you give me nothing to complain about, nothing to hate, nothing to have to apologize for. Just an ever more amazing computing experience! For which I say, thank you very much.

Yeah, it's true Slackware is better than perfect ... that should be the new motto.

Yeah, but then you'd have to merge the change with every release.

There is no rc.local_shutdown in any of the packages, so that's not a problem.

Forgive me if this is a dumb question, but scripting is something I'm not very experienced with. How do you ensure that it's going to execute on shutdown rather than bootup?

If executable it's called by /etc/rc.d/rc.0, rc.K and rc.6, only.

PS In Slackware rc.0 is a symlink to rc.6

Terrific; thanks.

Probably has been said, but I hate the fact that Slackware still uses lilo as the default bootloader. Lilo is simply antithetical to the flexibility of the entire system, and it's always the very first thing I throw overboard.

-A

Why do you hate lilo? I find lilo to be very flexible, it does what I want it to do. It boots Slackware perfectly and it also allows me to easily boot other operating systems on the same PC(Windows, FreeBSD, etc.)

The kernel 2.6.33.4. Why not chosen kernel 2.6.32.15 ?( long term support )

Because it was not yet out at time of Slackware release, I guess ;)

Why not 2.6.27.47 then, LOL

I also regret that choice.

Slackware 12.2 worked out wonderfully for me as it used the 27 series which was the previous long-term kernel.

Greg K-H has already announced that 2.6.33.6 will most likely be the last in the 33 series so 13.1 is going to find itself with an unsupported kernel very early in its lifetime. Updating to a newer branch is an option, but that means that your platform is no longer "stable", which may be a factor for some folk.

Big players like RedHat, Canonical, and Novell, and maybe even debian have the resource to back-port important kernel updates to their stable releases once the kernel devs drop support. The Slackware team aren't in a position to do this, so choosing the right release kernel is all the more important.

IMO Slackware got this one wrong this time. It's too late to do anything about it now though. That horse has already bolted, but there's possibly a lesson here for the future.

The .32 branch was announced as a long-term kernel a good month or so prior to .33 hitting current. I was very surprised to see .33 hit current at the time.

I know you were being sarcastic about .27, but the difference is that .32 is not obsolete. It's the current long-term supported kernel. In some respects it's more valid a choice than .33 is now because .33 has already been superseded by .34.

It is not common practice for Slackware to add new kernels to the patches section of a stable release - except in some cases to plug a critical hole.

No one is stopping you from adding a new kernel to your Slackware system. Unlike Redhat/Novell who keep backporting fixes and enhancements from new kernels to old releases, Slackware assumes that you pick the kernel that suits you best. The use of vanilla kernels in Slackware makes a switch very easy.

The 2.6.33.x kernel was kept in Slackware 13.1 because it works with some devices that are not supported by the 2.6.32.x kernels (at least some netbook network cards), as well working better with our X.Org for Ati cards in particular. Also, ARMedslack required something newer than the 2.6.32.x kernel.

Eric

While it's true that most people can just track the latest kernel branch and make their own custom builds to keep updated, there are times when stability(in the non-changing meaning of the word) is desired and the long-term support kernel is provided for that purpose.

Though new kernels tend to be backwards compatible with older kernels and the libc/headers built against them, I'm not convinced it's safe to run an older kernel on a system with a libc and headers built from a more recent kernel. You might get away with it of course, but the danger is that a new kernel interface/feature was introduced and made use of in the library/headers and when you run on the older kernel that feature will not be available.


What I'm suggesting is that it's better to freeze libc/headers for the latest long-term kernel, regardless of whether you include a more recent kernel as a default runtime kernel as this will allow people the option to run either the default or revert to the long-term kernels if stability is important to them. If you wanted to be extra nice you could even include the long-term kernel in /extra as an option.

The nice thing about Slackware 12.2 coinciding with the long-term kernel was that it was possible to follow 2.6.27.y all the way up to 2.6.27.47 (released just a few weeks back). If Slackware 13.1 had shipped with the option of using 2.6.32, it would have been good for at least a good year or so, just like 12.2 turned out to be.

I am happy that Slackware 13.1 ships with the 2.6.33.x kernel as it supports the network card on this Toshiba NB200 netbook. :)

When checking disks while formatting during installation would be nice to have some kind of output, percentage or something like that so I'd know after hour of waiting if my computer blocked or it's just really really slow.

Just switch to console 4 (Alt-F4) where the output of the formatting process is being redirected.

Eric

If anyone's interested I built and am running the 2.6.32.15 with no problems that I can tell on 13.1. I just used a my custom .config from 2.6.33.3. I couldn't find a version of the config-generic-2.6.32.5 from a few months ago.

Wow! That means yoy're an expert in Linux. Plz tell me how to be that. Thanks.