Oops... that was very unfortunate!

The main page of that mirror has the following message:

Nothing new and exciting is being uploaded... it is only a broken mirror.

Eric

Whew!
I almost fell victim to that.
I think I'll start mirroring my local mirrors to be safe.

Yeah rsync --delete can be dangerous when stuff like that happens. You could investigate the --backup option I suppose, but I prefer to just tar my mirror up once in a while for safekeeping.

Second. I came to realize that unless I regularly (like, yearly) freeze permanent, untouchable snapshots of everything I have, it's only a matter of time before cosmic rays and/or an incorrect rsync call ruins a big chunk of my data. I am particularly concerned with physical corruption of something binary in the master copy: even if everything is signed, at best I will know that the data is corrupt, and not how to fix it. If I have 3 or more full copies, though, I can easily recover from a truly massive fail that happened unnoticed years ago.

Well, I haven't studied the Seamonkey changelog in detail, but just took a look into it, occasionally. As far as recent updates are concerned, most of the changes are only relevant on Windows. Regarding fixes for serious security issues, Slackware has been one of the fastest distros to react upon, in the past, as far as I can tell, and it although there's no heavy backporting, Slackware gets longer updates and fixes than most commercial operatng systems get even for lots of money.


True, but that makes a lot of sense to me. How helpful is a backported fix, if it has unwanted side effects, and breaks things or harnesses stability? Pat V. and the crew are doing it just right, IMHO!

gargamel

This is all good information. Thanks!

That doesn't seem to jive with the security updates.

Here's one of the more recent ones:

In fact, it seems that all security updates are backported to Slackware 12.0 except for Mozilla products. And of the Mozilla products, Seamonkey seems to be updated least of all.

I suspect that the Mozilla products are difficult to update and require updates to dependencies (like Cairo) that has a risk of causing a cascading, dependency-hell situation.

Still, as noted above, browsers and e-mail clients are the biggest security risk we have.

Regards,

Seamonkey will compile but you may need to get the latest version of it's dependecies to build it without errors. Another good thing also to do is check the SlackBuild script and remove any special comments and patches from the listing unless they are absolutely for that version. Often Patrick patches stuff specifically for Slackware but you often can get away with running the configure script with some of Patrick's pre-built options and build it by hand with make, or use src2pkg.

The 2.4.1 binary and source tarballs are available and will work on Slackware. For the binary, Just drop it into the /opt directory and remove the version from Slackware and create a symbolic link to the /usr/lib{$ARCH$}/mozilla/plugins directory within the Seamonkey directory. For the source just build it vanilla style using Patrick's script and make sure you remove the patches for 2.3.2 ONLY (usually these are .diff files).

Reaper,

That's good information. I'll give the binary a try and see about building Seamonkey from source again.

Each time I've tried it, I've run into errors. My attempt to build it from source on 13.1 ended during configure because it was looking for newer versions of Cairo and something else. I could modify the configure script to accept my current versions, but I haven't done so yet.

My attempt to build it in 13.37 failed during make, but I overlooked the patches. I'll look at it again.

Regards,

13.1s packages are rather dated. You may need packages from -current. If you ever want to get -current use AlienBob's script for getting -current. Easier to stay up to date using current.

BTW I run Firefox 8.0 with the developer package compiled from Patrick's SlackBuild and I run Firefox Nightly 10.1a1 and Seamonkey 2.7a1 binary packages out of the /opt directory in sync. Honestly, I like Nightly better than mainstream builds.

Reaper,

I got the 64-bit Seamonkey binary from Mozilla and dropped it into /opt with the symlink for plugins. Everything works great and I'm happy again. Thank you.

I've actually got a lot of experience building from source, but sometimes it's nice when the binary just works.

For that matter, I'm running Firefox 7 from the Salix binary, and that's running well too.

I haven't yet upgraded to 13.37 (kids, work, other stuff have kept me from the upgrade), so it's nice to have up-to-date software.

Regards,

@lufbery

"Backporting" in the manner that BlackRider and I were using it refers to the situation where an upstream project find a bug and fix it in 2.3.x, but won't fix it in older versions which they have decided to no longer support. If a distro is shipping 2.2.x and can't or won't update because of stability/compatibility concerns then they will either have to live with the bug or 'backport' the fix from 2.3.x to 2.2.x themselves (or borrow the patch from someone else who has already done it). The kernel is a good example of this in practice.

The httpd update you gave as an example is just a normal update that Pat was good enough to make available for older releases of Slackware and is not really an example of backporting in the context we were using the term.

Though I don't want to speak for him, from what he's said in the past I believe that Pat thinks that upstream projects have a responsibility to look after their own stuff and the distro maintainers shouldn't be expected or required to mess with it in this way. I don't particularly disagree with this point of view.

1 members found this post helpful.

In an ideal world, each upstream project would establish a policy regarding security maintenance for old versions of their software. In our actual world, most FOSS projects have no manpower to maintain too many versions of their work, or the will to do it.

In addition, remember that the fact that upstream gives long term support for a given piece of software does not mean that it will be supported for the whole live of a given version of a distribution. What happens if upstream support lasts 18 months, but your distribution has a life cycle of 7 years? You have to remember too that distributors usually include non-upstream patches in their packages, so upstream's fixes could not apply properly and should be adapted by the distributors that messed the packages in the first place.

What I mean with all this is that, unless your packages are 100% upstream (like most in Slackware) and upstream provides security support for long (very unusual), distributors are going to need to backport the fixes themselves or, as Patrick does, upgrade the whole affected software when possible. As of today, I don't think the last option is possible for long term distributions.

Take Firefox as an example. Last version won't compile in an old Slackware. Most distributions would backport the security fixes to their own packages, so their users would have a "secure" browser even if upstream does not support it anymore. In Slackware, you are likely to not have the problem fixed. Worse yet, for many other apps, the average user is unlikely to even know there is a security weakness in a given package. Security aware users (those who keep an eye on IT security sites and the like) will have to fix the problem themselves.

This is the reason why I think the way security is handled in Slackware is suboptimal. You never know when you are going to miss a given security fix without being warned, unless you get informed by a third party security source and provide a fix yourself. The fact Slackware 8.1 is still being updated from time to time does not change the fact that any security fix that cannot be easily ported to it won't be ported by Slackware Inc.

1 members found this post helpful.

Indeed, the development model is far from ideal so in the real world there are implications. I don't disagree with anything you have said either.

IMO Rolling-Release is the only mechanism that makes much sense, but when your business model revolves around selling box-sets of new releases that's not really an option.
OpenSUSE's Tumbleweed sounds about on the right track to me. It'll be interesting to see how well it works out.

I don't know of any vendor with a support as long term as slackware's, but maybe it's me

remember that slackware gives you the possibility to easily update stuff yourself using the slackbuilds provided: for example, I'm running firefox-8.0b2, thunderbird-7.0.1 and seamonkey-2.4.1, built on 64current with Pat's slackbuilds on a fresh slackware64-current with no issues.

If firefox is unsupported on an old slackware because the minimum requirements are higher, you probably have to rebuild dependencies yourself (but for that I think you could only possibly blame mozilla coders) but you can also switch browser.

if they want their software included in any distribution, I think upstream *must*, at least, provide security support, in a ideal world.