Agreed. I hope I've been clear in my comments above that I think the Mozilla products are actually a bit of a pain to: (1) compile and (2) keep up with.

Thankfully, newer versions of Flash (which you can get from Eric "Alien Bob" Hameleers's repository) has not to terrible security settings.

No Script is a Godsend! So is Adblock Plus. Embedded ads cause problems with browser stability, load times, and security.

Regards,

I'm doing just that in a QEMU-KVM machine running Slackware64 -current. I just got it installed today, but so far, so good.

Regards,

I really think that Mozilla "suicided" their browser when they chose this new pseudo-rolling release developing method. Not everybody wants to upgrade to a new major version version of a browser every 6 weeks (and they have told us they they plan to do it faster in the future). Firms are not going to use such a chaotic piece of software when they can use one that just releases a major version and then supports it for a year.

My only problem is that I don't like Chrome and that Opera is not free (as in speech). Arora, Midori and the rest are nice if you don't need too much candy in your surfing, but if you want a full featured piece of software, they are not enough.

Text-based browsers remain my favorites, however, as they are compact, secure and fast. I think there's only an unpatched serious CVE for Lynx in Slackware.

I "almost" agree with (1). Last time I checked here, many CVE were related to Windows only. All I can say about (2) is that I don't use Adobe Flash: it is non-free, bloat, has a bad security record, and they are trying their best to force you to use it. Screw them! About (3), I have to say that NoScript really helps, but I complement it with:

-->> Certificate Patrol: Helps you preventing MITM attacks as the ones that could have derived from DigiNotar's compromised certificates. If someone tampers with the certificates of your trusted sites, you will get a warning with a lot of info.

-->> Request Policy: Prevents evil redirections and undesired content from walking into your path. Nice to protect against contents that would not be blocked by NoScript.

I wouldn't mind the rapid updates from Firefox, if they did it a little different, and there was an actual reason for the update. It's annoying for every point release to suddenly have non-compatible plug ins. There's no reason for this. Seamonkey should not be following this asinine method either. These releases barely qualify as a point release, let alone as a major release. Firefox is inflating version numbers just to inflate the number.

Mozilla stated one of the reasons for the move to a rapid release cycle was, they where worried with Google Chrome updating so rapidly, they (Firefox) would lose market share. Funny how once Mozilla moved to this rapid release schedule their market share started to slide.

Perhaps we need to start re-packaging the upstream binary as it was done in the past.

Unless something has changed recently, they don't make x86_64 binaries available, which was another idiotic decision from them. 64bit has been far from exotic for quite a while now.

Again, I find myself in agreement with BlackRider. It's almost as if they are intentionally trying to shed market-share.

There are definitely 64-bit binaries, e.g.

ftp://ftp.mozilla.org/pub/firefox/re...-7.0.1.tar.bz2

Salix have Firefox 7.0.1 Slackware compatible packages for 32-bit and 64-bit. They just repackaged these binaries into Slackware format.

I'll quote myself, since I provided links last time to the Salix packages

1 members found this post helpful.

This is the Salix Firefox build script. You will note it is not a traditional SlackBuild as Salix tends to use slkbuild to create packages (it is a meta script they created to simulate something similar to the Arch PKGBUILD system).

You can either user this script directly if you download and install slkbuild (it works find on real Slackware), or it would take very little effort to convert it to a regular SlackBuild.

I have very little bandwidth, so I don't want to spend the time it takes to download each extension again. What I usually do is to "hack" each extension so it reports itself to be compatible with the new version of Firefox. I have been doing it since Firefox 4, and does work most of the times. It just takes a few keystrokes.

They certainly didn't used to, which was why the SlackBuild used to repackage the pre-compiled binary for 32bit and had to compile from source for the x86_64 version.
It's a welcome development though. Perhaps returning to the repackaged binaries is a good idea then.

There is another way: in about:config, set extensions.checkCompatibility.7.0.1 to false.

5 members found this post helpful.

Thanks for that!!!

At the time Slackware64 appeared, there were not 64bit binary builds readily available.

64bit binary builds have been available for a few versions now. Seamonkey's x86_64 builds are considered contributed and not official though.

Doesn't really matter to me, as I build Seamonkey myself since Pat trimmed out most of the header files. Seemed like each time I added one or two header files back in for application A, application B would then complain about something else missing. Tired of playing hunt and peck with header files, I include them all.

1 members found this post helpful.

I don't think Patrick trimmed the headers. Patrick uses vanilla sources so if there is any to blame it's Mozilla. The alternative is to grab a copy of XULRunner, build, and install it.

If you want the latest Mozilla, do what I did, get the Nightly binary, unpack it to your /opt folder, symlink the plugins directory, and rewire your path(s) to Firefox to the Nightly build.

I've only had one thing not want to work right which was Gecko-MediaPlayer but I recompiled with a newer version of XULRunner and reset the GCONF support, and it fixed it.

As stated, if you want security and the latest stuff, learn to do stuff outside the box and maintain your own system. That's real systems administration, and if you don't like it (and sorry to be blunt) find another distribution that uses a lot of untested bleeding edge code.

Slackware is what YOU make of it.

You really don't have a clue do you?

I'm only going by what Patrick has openly stated in the past.

It is the upstream source, but the SlackBuild decides how and what is included from this source.

Usually the Mozilla headers are handled by Xulrunner. Considering Slackware does not include Xulrunner, we've (as Slackware users) always relied on Seamonkey. This removal of the header files is new in current. You can read the SlackBuilds and see the change.