On this box with 8GB of ram, all four CPU's running at near 100% I was watching YouTube videos while waiting for the compile to finish. Was it a bit sluggish, yes, unresponsive, no. I didn't try to SSH to it from another box, but I am 100% certain would have been able to. Was swap in use? Yes it was. Like I said earlier, the compile took a couple of hours. I think I'll try it from my laptop.

Wait Frontier or EL-Capitan ;-)

i'm use dual core AMD BE2300 2 Gb RAM, but all good compilation from 1 night up to 3 day's !
But i can use ready Firefox from him site.
OpenSUSE build service is ready to use too. https://openbuildservice.org/
Is not a stop.

I mean Firefox 86 and UP line is ready to mainstream now. But Developer Edition.
https://www.mozilla.org/en-US/firefo...edium=referral

" Firefox Browser Developer Edition
The browser made for developers
All the latest developer tools in beta, plus experimental features like the Multi-line Console Editor and WebSocket Inspector.
A separate profile and path so you can easily run it alongside Release or Beta Firefox.
Preferences tailored for web developers: Browser and remote debugging are enabled by default, as are the dark theme and developer toolbar button."
Attachment 35851
"New Tools:
Firefox DevTools
The new Firefox DevTools are powerful, flexible, and best of all, hackable. This includes a best-in-class JavaScript debugger, which can target multiple browsers and is built in React and Redux."
https://download.mozilla.org/?produc...x64&lang=en-US



My web's:
http://7cyber.usluga.me
https://vk.com/7cyber
https://vk.com/dyabaru

Well, that box of mine with Intel Core i3-3220T and 8GB DDR3 1600MHz was utterly defeated by this Firefox build. It ended on a full freeze/unresponsive state.

And so did also the other boxes other than my main computer, which does fine this job.

Considering that you claim that the Firefox build worked for you on a box with 8GB RAM, probably another element enters in the game. Probably the hard drive?

True, I for one, I have a SSD only in the main computer, the others have mechanical/rotational hard drives.

Anyway, looks like the Firefox build may or may not work on a quite decent box with 8GB RAM.

BTW, I could ask you why you are against the addition of an alternate Firefox package on -current?

In the end, I do not asked to be replaced the package of Firefox for Enterprise, but for an alternate package.

After all, for Mr. Volkering would be probably matter of minutes to build a whatever Firefox package on his 44 cores build farm, while us we should struggle at least for hours with this, even may we will not end on unresponsive systems.

I use https://ftp.mozilla.org/pub/firefox/.../linux-x86_64/ version, since longtime.

uncompress it, in /home/me/firefox

linked the exec on the desktop or taskbar, and that work fine. ;)

You could try it without misusing your ram. Let the hard drive provide /tmp and swap. (You didn't use PGO, did you?)

I used on my tests the standard mozilla-firefox.SlackBuild as provided by Slackware, having enabled the CLang after the instructions given by @Ponce - this happened before, because now it uses the CLang by default.

And yes, the /tmp is just a folder on root filesystem and the swap is a standard Linux swap partition of 8GB.

So, I do not think that I misused my RAM in some way.

However, I will say again, to be very clear that, I for one, I have a box to do this job: my main computer with 16GB RAM of DDR3 1333MHz and a CPU of AMD Athlon x4 605e.

So, I do not did this discussion about building Firefox from an egoistically POV... ;)

My claim is factual, I built it, I am using it now. I'm curious as to what element made this possible, hard drive, I think not.
I am currently building Firefox on my laptop. I used "time" for that run. I gave the inxi -C -m specs on that in an earlier post. This laptop does not have an SSD drive.

Agree with may or may not, yet I have done so on this box and waiting on it to complete on my laptop with 8GB RAM.

This is what I said.
Where in that statement does it say I am against this. That is your take (and apparently a few others) on my post. I simply saying that I can built it, so who needs extra. I could have said "you can just build it", I didn't, either way that does not mean or even imply that I am against it.

When Firefox ESR because somewhat of the staple in Slackware (around 14.0 or so), I was building the Firefox release version using the contents of /source/xap/mozilla-firefox/. As time progressed, this became more of a task to get a successful build. May last attempt was with Firefox Eventually I just rolled with Firefox ESR. With this latest change building from the source tree is again as simple as plugging in the source tarball and running the SlackBuild.

Aside from the development branches of Firefox there are only two release branches. The Extended Support Release ESR version and Rapid release version. The Firefox for Enterprise is the Extended Support Release which can also be used for Personal use.

If you not up to building from source, then there is ruario's latest-firefox.sh script. I works just fine.

Well that is his decision to make. I'm fine with what ever he decides. Putting the "Rapid release" version in extra, would be fine with me. Firefox used to be part of Slackware, until this rapid release stuff started.

About what "rapid release" you talk? There's no such thing.

Let's do some facts check, according with Mozilla: https://www.mozilla.org/en-US/firefox/browsers/

So, the Mozilla itself claims that those are the types of Firefox:

- Desktop, the one made for home users and which I proposed to be added as an alternate package, after long years of successful usage of it, both on Microsoft Windows 7, 8, 8.1 and 10, and different Linux flavors, including 5 years of Slackaware -current.
- Mobile, the one for Android and iOS smartphones and tablets - I hope that there we will not disagree.
- Enterprise, the one which is shipped today on the main tree of Slackware and which you claim being @TheRealFirefox.
- Reality, the one made to have a 3D interface, for Virtual Reality devices - I hope again that there we will not disagree.
- Developer, which essentially are the beta Desktop releases with some additional tools enabled.

Again, there's no such thing like a "Rapid Release" of Firefox - all those four stable types of Firefox have often published releases.

BTW, this is the box which failed multiple times to build Firefox - and while it's my usual second box, there are another 10 boxes with various (old) hardware, which glorious failed to build it.
While this is my main computer, which always succeeds to build Firefox.

I dug into this further. The issue stems from the mmc_block module having an internal name of mmcblk. This means that the script in mkinitrd to generate the module list misses it.

I put in a specific workaround for this in the patch below. A little ugly, but gets the job done. And can't think of a much better way given the mismatch in the module's module and internal name.

Andrew.

seems to be a little misunderstanding here I deliberately installed _that_ FF as my "user" so it can update itself....

-rasp

OK, I tried it, too. My Pentium 4 with 3.25 GB of RAM just built firefox-86.0.1 successfully using slackware64-current and kernel 5.11.6. It took almost 12 hours of wall clock time. There is only one core but two hyperthreads per core, which made the slackbuild use NUMJOBS=3, and it still could manage it.

I use bfq as the io scheduler, so the interactive use does not suffer too much from the heavy i/o during compilation: scsi_mod.use_blk_mq=1 appended to the kernel command line and this as /etc/udev/rules.d/55-disk-scheduler.rules

LuckyCyborg au tableau d'honneur :-)
 

Mod. Please delete.
Posted in wrong topic.
Thanks.

Pat,

By popular demand looks like Slackware is back on the rapid release version of Firefox. Please consider adding ESR to /extra.

Thanks.

Just from using the ESR channel you can see that it doesn't update as often (less "rapid"), but anyway, "rapid release" is Mozilla's own terminology: