I do not know, because I do not use those particular plugins.

Yet, all my own used plugins works like a charm on both 52.3.x and 55.x.

BUT, how about you to do a try of 55.x and to see yourself if your plugins (still) works or not?

Reporting back the results would be nice, thought...

It's too much hassle setting up -current just for that. I thought you might have ensured all these things were working before insisting on the change!

1 members found this post helpful.

If you really want, no one stops you to test the thing also in your stable installation...

So sorry that I have not enough time to test all those 100000 Firefox extensions!

In other hand, as personally I use the Firefox with some really heavy extensions for web-development, I guess that it behave OK for most of them.

And talking about my own "insisting" on this change, look...

On all the release cycles since 12.0 always the slackware-current used to push the latest Firefox. I was there, I remember.

The real shocking change is the push of an ESR on the current development cycle, you know...

You don't say? It's almost as though picking packages for a distribution requires more than looking at the version number and choosing the highest ;-)

2 members found this post helpful.

Remember that when you see pushed the latest GLIBC, GCC or X.org, which really break the things...

For gods sake! I show you that that damned Firefox made real improvements in the latest releases, I do not ask you about adding PAM or SystemD here!

It is about a freaking web browser!

You do realize that the average user doesn't have 100+ tabs open, right? People see my browser windows with all their tabs and they're always amazed that I can even function. For the way most people use Firefox, its memory consumption probably isn't a big issue.

Yes, I'm excited to see how this new Firefox performs to see if it will finally make me move back from Chrome, but I am not willing to try and demand Pat and team to add it immediately to Slackware, whether stable or -current. I'm working to tailor the official SlackBuild to build this new version (the first time failed and now it's working through it again) and then I'll give it a run.

But this isn't *my* distro. It's Pat's. It's up to him on when to make changes, not based on forum members whining that their very specific usage of Firefox uses too much memory.

And to give you an idea of my browser background, my main Chrome *browser* process (not the forked processes used for extensions and webpages) is using 1.2GB of RAM right now. The top 4 forked processes are all using over 500MB of RAM, so I'm easily pushing 4GB+ with Chrome (probably a lot more, but I'm too lazy to check it). I'm excited for any prospect of lowering memory consumption, but it's not my place to *demand* things from Slackware. If I want something and they haven't done it, I can *politely* request it on the forum, do something about it myself, or wait until they add it. I don't understand your constant need to whine to the Slackware devs just because they haven't done something that you want. You really should grow up a little and show some professionalism on this forum.

Exactly! It's a freaking browser. Why are you so crazy over a browser? Especially when you can use ruario's script to repackage the latest version into a Slackware package?

6 members found this post helpful.

So...ignoring the arguing between different people right now I had a few questions with respect to the RUST/firefox thing:

1. Is RUST a compile time or runtime dependency? After all, if it's just a compile time dependency someone could just have RUST on their system and build firefox for us and then distribute the package.

2. Is there an option to build firefox without the system's RUST? Let us suppose RUST is a runtime dependency. A lot of mozilla projects (firefox included of course) has a --without-system-foo and provide the files for building with "foo" support without having to have it installed on the system. Then RUST could simply be compiled into the binary (perhaps an option like --without-system-rust or something exists).

Not to side-track an illuminating conversation, but it's Rust not RUST (i.e. it's not an acronym). Check out the Rust homepage: https://www.rust-lang.org.

1 members found this post helpful.

As far as I know, it is only a compile-time dependency and not needed for runtime.

I haven't had a chance to check it much yet, but I did finish a compile of Firefox 55.0.1. I had to add rust and cargo (both on SBo) for compilation, but I was able to remove both and still open the upgraded version. If anyone wants to test it, you can grab it removed (64bit only).

1 members found this post helpful.

I don't understand the original post but, I do have a couple things to say about Rust and Firefox as mainly a Linux From Scratch user these days.

1. From everything I've read, Rust has great potential as a modern compiled language.

2. I don't know why it is being used in production. Everything I've read thus far has explained that its API and language specification are both unfinished. Firefox, nor anyone else should be using it in production code. This is an engineering no-no and people should know better.

3. Cargo is more OS/FS build pollution. Worse, to my understanding, its designed around pulling down the latest commit. This is bad. Releases exist for a reason. Imagine the chaos it would create if everyone built from the kernel master that changes all the time. To me, this is just more proof to me that software developers are utterly clueless of what goes on in software distribution. This sort of thing creates unneeded and unnecessary load on both disto maintainers and System Admins. I will clap when they publicly post that they will no longer incorporate or maintain such packages.

4. If this forking and dependency madness continues on modern web engines, I suspect we'll see them go the way of TeX Live. But, that's probably how the sponsored ones want it. That way they can incorporate all the web-spying and HTML DRM they want.

11 members found this post helpful.

Maybe there will be something like gcc-rust in the future, like gcc-java solution for things that use java.
Not sure if possible, but seems elegant enough solution.

About web-spying I completely agree with above post, it's just company politics & has nothing to do with technical advance.
I'd recommend everyone to open about:config and search for 'http' it's the best way to draw own conclusions from that.
Also the DNT feature is a lie, I've read about it and I assume the original idea was to strip headers, while the end results just adds an additional header.
It's useless tracking 'protection' that only asks tracking websites not to track, it doesn't strip nothing even though it's technically possible.

I run regular 14.2, but I'm actually wondering why the Firefox package in -current was ever not the ESR release? If stable Slackware goes with ESR, then why wouldn't -current also contain ESR (since it's the testing ground for the next stable Slackware version)?

For what it's worth, I use Slackware's ESR for my main browsing, but I also use the latest binary release from Mozilla (currently 55.0.1) which is configured specifically for work.

No, Pat hasn't "surrendered" to the technical difficulty of building a distribution-suitable Rust package.

Do you know what that "surrender" would look like?

Packaging a prebuilt binary of the Rust compiler.

I assume he's still on the I'M NOT READY TO GIVE UP AND DO THAT YET!!! phase.

7 members found this post helpful.

Disclaimer: I have no certain knowledge of the Slackware team's reasons, so what I say is speculation.

My guess is, since the FF devs introduce surprises into the project gradually (build req changes and bugs), it makes sense to build and provide each FF release. This way the req changes can be discovered and puzzled out ahead of time, and -current users can find the bugs ahead of time.

If only each ESR were built, all of the build req changes would be encountered at once, and all of the new bugs introduced at once, which would be harder to troubleshoot than if each problem were encountered in isolation from the others. It would also give -current users less time to find bugs introduced in previous releases.

For instance, say hypothetically v56 introduced build req "X" and v57ESR introduced bug "Y". If you hadn't tried to build/test v56 before v57, you wouldn't know if "Y" was a consequence of "X" or independent of it, and might spin your wheels for a long time chasing incorrect solutions.

The only possible counter I have to this is the possibilty of downgrading the -current non-ESR version to an available ESR version when -current becomes stable. If, for example, Pat is shooting for a December 2017 release of 14.3 or 15.0 or whatever version, the latest ESR would still be v52, so if he were to keep an ESR in the stable release, he'd have to downgrade from what would likely be v58 or v59 (v59 isn't scheduled to go to ESR until end of Q1 2018). (Source: Firefox Release Schedule)

But if Pat were still more than 6-8 months out from an expected release, it would be possible that v59 will be ESR at that point.

But as ttk stated, this is all just speculation. We don't know why Pat hasn't added newer versions in yet other than his post here. Unless he provides more reasons (or an updated package), we are left to either stick with his available packages or find new ones to use. I've already provided one using Pat's mozilla-firefox SlackBuild after adding rust and cargo to my system. As before, I haven't had much time to test it (I can't compile it on my main 14.1 install because things are too old, and my 14.2 install is mainly used for my htpc with little to no browsing on it).

1 members found this post helpful.