I can't say I'm surprised, mate. Like most of these cloud-hosting sites that offer the option, I suspect MediaFire have a heck of a lot more 'free' users than they do 'paid' ones.

I guess it's a case of make a buck or two wherever they can.....and if having to view a few ads is the price for access to the download for a brilliant browser, then.....so be it!

I think I can live with that. MediaFire have been as good as gold the last 2 years for me; they even promptly sorted out a cock-up (on their end) that stopped me accessing any of my stuff for a few days, a while back.

Wanted to update about getting Slimjet (and Chrome, Iron, and all the blink browsers) working in either mini and/or full-build installs of Debian using the "silent-launch" feature (something that I am without shame addicted to now). All I can say is this: make sure you triple check when you set things up for silent-launch, if you are copying things over from Mike's SFS. You cannot imagine (or maybe you all can) how an intended space where there should be none can drive your best intentions to the funny farm

Silent-launch is now working across my Debian landscape despite myself, lol, and it is working all along with the pup watchtowers too.

Have a question for ya, hope it's something easy: since I finally got Slimjet installed (both using your great 64bit-sfs and also directly downloading it from Slimjet site for 32-bit)...but since I finally got it installed across my 32/64-bit puppy kennel, I am running into numerous problems with Slimjet and Youtube. Using an example from XenialPup (but the problem applies across many pups & Ddogs), it's best described by these pictures below. Are you seeing anything like this, and is there some simple fix (or maybe some setting) I am not considering? Thanks for any help/tips!

Question; Are you having this problem with both 32- and 64-bit.....or just 32-bit?

I ask, because I've not been able to access Google, or indeed any Google-related site (and YouTube is part of Google's empire) since the release of Slimmie 14; that's when they made the switch to a Chromium 57 base. It's a big part of the reason why I switched to DuckDuckGo as my primary search engine.....and I certainly don't regret the move.

Yet the problem seems restricted to the 32-bit version only. The 64-bit version functions as you would expect.

I think this is Google being 'pushy' in their 'Big Brother' way, and attempting to speed up the switch to blanket 64-bit usage across the board. Apparently, in Windows, they're attempting to force the 64-bit upgrade on everyone, whether their systems can use it or not.....even 32-bit ones. Which strikes me as a wee bit over-zealous.

We know 64-bit is supposed to be safer, and more secure.....as well as being able to access much more up-to-date features, and a hell of a lot more RAM; necessary with all the video-streaming that occurs all the time nowadays. Those videos need processing.....and that uses even more of the stuff.

The problem is there on all Chromium-based 32-bit browsers. Iron's affected by this, too, as well as Chromium itself. And what everyone seems to forget is that Google control the Chromium Project. They sponsor it, and draw their own source code from it. Makes me laugh, all these folks who say they hate Google, and yet are happy to use Chromium. 'Oh, it's open source.....and it doesn't 'phone home' to the 'mother-ship'.....' Only because the API keys are disabled in the build.....but the design, and direction, of the browser itself is strongly influenced (read, dictated..!) by Google themselves.

And what Google have made no secret of is the fact that they believe everybody should make the switch to 64-bit computing, ASAP. They don't want you using 32-bit. Which makes it all the stranger that the Chromium Project are still developing a 32-bit version.....

At the time of the imminent release of Chromium 56, there were rumours floating around that Google wanted to become their own certificate authority. I think they've pulled a sneaky one, keeping the 'empire's' various site certificates up-to-date in the 64-bit release, while allowing those for the 32-bit browser to expire.

Just their way of giving you a 'nudge'...!! I think you're stuck with it. FlashPeak themselves can only work with the source code that they're given. I don't think there's a way to alter, or 'upgrade', the certificates.....or, if there is, then I've not found it. You're supposed to be able to add certificates to the browser yourself, but you'd have to find a way to not only use the 64-bit certs in the 32-bit browser, but also find a way to fool Google's servers into thinking that you are, in fact, running 64-bit hardware..... This is why I always keep a copy of Chrome 48.0.2564.116 around; the final 'true' 32-bit release before Google pulled the plug.....because it has none of these problems. It just 'works'.

The previously-mentioned 'silent-launch' feature has been added to /root/Startup; if you look in /root/Startup, you'll find a new script, entitled 'silent_launch_slimjet'. What this effectively does is to launch SlimJet at boot, without 'opening' it; rather along the same lines as how modern Windoze works with hibernation and Fast Startup; it essentially holds it in 'standby-mode' until you launch from either desktop launcher or Menu entry. Upon doing so, it starts almost instantly.

If you don't want to make use of this, or wish to disable it, simply delete it from /root/Startup (or comment out the second line).

15.1.3.0 running well on Thar64, though I still get the insufferable "cannot run as root" messages and I have to config to start with the -no-sandbox clause. This is always an issue with Slimjet, especially in 64 bit.
Still, it runs fine (without sandbox), and has replaced Palemoon as my browser of choice, due to its functionality. My favourite add-ons - Privacy Badger, Lastpass and Spotify Web Player - all work without trouble.

Y'know, I don't understand why you're getting this problem with the sandboxing. That should not be happening. Neither in my 64-bit builds (I use Iggy's libpuppygc.so 'workaround', so I can use the sandboxing as normal), nor Oscar's.....and Oscar, with the 32-bit builds, uses PhilB's 'bbe' script. Both run with almost full sandboxing, as far as I'm aware.....

Y'know, I don't understand why you're getting this problem with the sandboxing. That should not be happening. Neither in my 64-bit builds (I use Iggy's libpuppygc.so 'workaround', so I can use the sandboxing as normal), nor Oscar's.....and Oscar, with the 32-bit builds, uses PhilB's 'bbe' script. Both run with almost full sandboxing, as far as I'm aware.....

Odd.

Mike.

I've also got the root nag and inability to run without --no-sandbox in your 15.1.3.0 Tahrpup SFS running on Battleshooters XFCE_XenialPup r2. I just installed that to chase some kernel 4.13 issues and it runs so very well I decided to use it for a bit and of course I can't live without slimmie. With the flag it comes up and runs perfectly. Any ideas on what I should root around in to try and troubleshoot that? I've been running OscarTalks 32 bit builds on all the rest of my pups with no problems at all.

Cheers,_________________Pups currently in kennel LxPupSc, X-slacko 4.4 and X-tahr 2.0 for my users; LxPupSc, LxPupArtful, ArtfulPup & XFCE_XenialPup64 for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Tahr64 is the only 64-bitzer I'm currently running, so of necessity it gets used as the 'test-bed' for a lot of stuff. I don't know if there's something slightly 'off' with my system, but when lots of people report a given problem with Tahr64, you can nearly always guarantee the exact opposite is happening with mine....

And for some odd reason, it point-blank refuses to run from a flash drive. I copy it over, run Grub4DOS, and rename the save-folder for the main Tahr64 on the hard drive so that it doesn't get used.....but it won't boot from a USB drive. It always results in a kernel panic of some kind.

All I know is that using Iggy's 'libpuppygc.so', I get almost full functional sandboxing on my 64-bit browser builds when I've created them. Which is the reason I can't understand why other folks get problems with 'em.....

The only thing I can think of is that it's found a user-dir-profile from a significantly older version of Slimmie (like, say, the 13-series?).....but then it'll usually complain that the profile is from an older version, and tell you it can't use it.

Hmm. I really don't know, mate. Have to stir the old grey cells into action, and see what floats to the surface..! Leave it with me.

[If you open /opt/slimjet/flashpeak-slimjet with Geany, what's the exec-line down the bottom of the wrapper-script reading? Can you do me a copy/paste, please?]

Too many decades since I played in a sandbox I guess _________________Pups currently in kennel LxPupSc, X-slacko 4.4 and X-tahr 2.0 for my users; LxPupSc, LxPupArtful, ArtfulPup & XFCE_XenialPup64 for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

Well, I've checked the SFS all the way through for permissions; everything looks as it should be.....'root' ownership all the way. These have to be adjusted during the build, since the 'slimjet' folder, as downloaded in the tarball from FlashPeak, has a few items with 'ftp' ownership...and if I don't 'adjust' them, I get all sorts of complaints.

The only thing I can suggest is to try using Phil's 'bbe' script, which Oscar uses. Save it somewhere as a text document, but make it executable. Then, just drag the 'slimjet' and 'slimjet-sandbox' binaries over to it, and just 'drop' them onto it. They won't actually move, or change location, but the script changes permissions and ownerships to what's needed.

Well, I've checked the SFS all the way through for permissions; everything looks as it should be.....'root' ownership all the way. These have to be adjusted during the build, since the 'slimjet' folder, as downloaded from FlashPeak, has a few items with 'ftp' ownership...and if I don't 'adjust' them, I get all sorts of complaints.

The only thing I can suggest is to try using Phil's 'bbe' script, which Oscar uses. Save it somewhere as a text document, but make it executable. Then, just drag the 'slimjet' and 'slimjet-sandbox' binaries over to it, and just 'drop' them onto it. They won't actually move, or change location, but the script changes permissions and ownerships to what's needed.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum