I've not heard of "gmlive" before, but I just checked and it's an mplayer front end.

Also it looks like mplayer installs a lot more video codec packages than vlc does, so it's likely that installing missing codecs fixed your problem.

Might not be relevant to Devuan, but: I also suggest backporting ffmpeg, rather than using the libav fork which was released with Debian jessie (future Debian releases went back to ffmpeg).

Look upstream to see what's supported... (NV130 in your case)

https://nouveau.freedesktop.org/wiki/FeatureMatrix/

So he was, I forgot about that flying visit.

Got the go ahead for the refracta section at DUF.org.  fsmithred, just PM me with what sections you want setting up.  I'll get on it later today or tomorrow.

PM sent - don't worry about it, not many have been to DUF in the last 6 years or so...  I'll keep you posted.  But JD630 isn't around much these days so could take a day or two...  or a few weeks.

in your original posts, you've said that dmesg reports that the firmware loader prompts for: "rtl_nic.rtl8168e.2fw"

/lib/firmware/rtl_nic/rtl8168e-2.fw is part of the "firmware-realtek" package, not the one you refer to.

Install this and reboot (or remove and reinsert the kernel module) and after configuring the interface, it should work.

Try the netsurf browser

I'm sorry to hear it's come to this, it's a pity you didn't have a section at DUF.org, I'd have welcomed you there, as would the current admin (and previous admins).

Sadly these "free" forum sites tend to hold the users to ransom.  Much the same in the old days with ezboard - it was impossible to migrate elsewhere, they got you on the hook and wanted you to pay...

Unfortunately it's feasible to conceal "backdoors" in open source code.  For example, in the Linux kernel, where you have 25M + lines of code, it becomes difficult to audit (by contrast the whole of OpenBSD is less than 3M lines of code).

It comes back to Linus' law and why it's mostly an idealist stance: "given enough eyeballs, all bugs are shallow" (Eric S. Raymond)

But if the eyeballs aren't actually looking (s they clearly weren't with respect to OpenSSL), the bugs don't get found.  Bugs which aren't found can become vulnerabilities which can be found by certain entities, but not disclosed (for years, if at all) and exploited.

As Torvalds said two years ago:

https://www.linux.com/news/linuxcon-201 … s-torvalds

With that in mind you can see how viable it could be to find and conceal an exploit.  Unfortunately it's the kernel which is the one component you need to trust.  Despite the work of the grsec/Brad Spengler and others, Torvalds has publicly taken a very laid back approach to security and has been dismissive of "security people".

And now, with the arrival of systemd and similar software (from gnome, freedesktop.org, et al), you have even greater complexity, more "attack surface" and more code which has just been written with the aim to bring in raw functionality to the detriment of all else.

I've often wondered...

As I recall ESR was the bone they threw to corporate users.  This was because in a corporate environment every piece of software has to be evaluated, so a moving target like firefox on the "release" channel was difficult to deal with.  ESR was the compromise they came up with for this purpose I believe - It has nothing to do with Debian.

The new "release" model ("release early, release often" - as per the Linux kernel development or "aping whatever chromium are doing", as some saw it) was initially very unpopular with end users and many IT professionals alike.

ESR is just a code base "freeze" which is supported with backported security updates for longer.  It won't get all the functionality from the new "release" releases, but it should get security patches.

I'm not sure of the ins and outs of why Debian recently reverted back to firefox branding (someone here will know), but the reasons for iceweasel were that Debian could not comply with the Mozilla licence and still call the software firefox, if it was going to apply it's own patches (as it does with most other packages for the duration of a stable/oldstable release).

And as I recall the use of the logos and trademarks and using the name "firefox" were two separate issues as well.

Years ago there were numerous arguments on the old Debian forums about Iceweasel and Firefox not being the same, etc.

Any actual data...?

Have you tried the latest Firefox (56?) which now uses "rust"...?  Apparently according to anecdotal evidence and benchmarks it's "faster"... (or maybe it starts up faster...?)

Firefox has been "expanding" steadily for over 10 years.  Around version 2.x was the last time I remember it being "fast" and "lightweight".  This is effectively because Firefox is commercial (Mozilla foundation is bankrolled by Google, etc and has the google "safe browsing" spyware and geolocation built in) and strives to remain "current" and "competitive" to keep that revenue.

"Modern" browsers are anything but "light", obviously because they're not just for browsing HTML anymore.  The sheer amount of functionality built into chromium/blink, webkit, Gecko, etc makes them pretty heavyweight, combine this with the "feature creep" factor and the amount of redundant code (especially with regard to Gecko) and you've got something which will take hours to compile and need a lot of RAM.

Apple avoided Gecko (which had/has a lot of old Netscape code) and adopted KHTML for Safari, starting webkit in the process.  As I recall at the time, bloat was one of the main concerns and KHTML (Konqueror's layout engine) was cleaner and more stripped down.

I knew you'd built a custom kernel as you stated that you had not used an initrd.  I used Linux since around 2002 and used Slackware and Debian for years - I understood your post.  What I'm not familiar with is some of the newer tools and especially systemd - hence the disclaimer.  I volunteered help/advice because you were building a custom kernel - but no I'm not volunteering a hand holding session and all out solution.  If that were your requirement you should have specified from the start.  I usually equate those who build their own kernels as tinkerers and wanting to learn. i.e. I assume they'd be willing to engage and not wanting a quick fix to their self made problem.

Did you read this...?

Whether the standard kernel exhibits the behaviour or not, this is still your custom kernel and your effort to prevent loading of lpt/IEEE1284 drivers.  I was attempting to give some advice on that.  I apologise if this forum and the WWW as a whole cannot provide only the perfect responses tailored for you specifically and in such a way as to not offend your delicate sensibilities.

And I pointed you to modprobe configuration.  That is where kernel modules would be explicitly loaded.  Debian used to add quite a few there, other distributions do not as I recall.  Also a particular built in module can still cause a blacklisted module to load.  A different distribution's kernel could differ in this way.

Well that's not surprising, as you clearly don't want to learn.  You made it clear in a certain post that a "succinct solution" was desired.

As I said, no offence was taken regarding the references to OpenBSD, it's you bringing it up again and again, you made some comments and I responded.  You seemed to take exception to being corrected and having your nose put out of joint.  Reading Wikipedia won't tell you much about OpenBSD, though as you've no real interest in it, I'm not sure why you'd be reading about it anyway).

Not really, but just make it clear next time and subtitle your thread "succinct solutions only please".

Seems anecdotal, but from what you've said, I'm not surprised.  If you go to any *nix forum with an attitude like you've displayed here, the result will be the same almost every time.  I am usually thankful for any help I receive even if it's a pointer in the right direction or someone just making the effort and using their time.

Pale Moon is controversial.  It's seen by some as a "snake oil" product, because the performance claims generally don't add up.  It's a fork of a previous pre-Autralis firefox release (24 as I recall) and has some of the advances in upstream firefox backported in.

The binaries are also proprietary freeware, though the source is still available under the original MPL.

For me anyway, Seamonkey (the continuation of Mozilla suite v1.x) is a safer bet in terms of how it's developed, released and supported.  It also has the nice retro netscape style UI (which with a few changes can be downsized, text labels on buttons turned off, etc to make it look a bit more appealing).