+1 (and the fanclub is growing steadily)

To me it speaks volumes that someone will return to a thread over a year later and still having a problem with that thread and those posters, then go to another forum and post a tailor made screenshot, soliciting comments about how nasty the FDN forum is...  well you should have seen it 7 + years ago.

To his credit, headstick has helped people out at that site, but it's a thankless task, burnout is inevitable...  once burnout occurs, the FDN celebrity assholes gallery beckons...  it's then up to the burnt out remains to resist the lure.

There is this well known quote:

"If 386BSD had been available when I started on Linux, Linux would probably never had happened."

~ Linus Torvalds

(386BSD was a predecessor to FreeBSD and NetBSD.)

FreeBSD or something BSD derived would have probably been the current "Linux" had things been a little different.

I suggest that though a Devuan with a FreeBSD kernel would be interesting, it would not really offer much over a standard FreeBSD installation or that of a FreeBSD desktop oriented derivative such as TrueOS or GhostBSD.  It won't really be of interest to current FreeBSD users.  FreeBSD's package management has come on leaps and bounds, so it's now possible to install all binary packages using an apt like tool called "pkg".

It would however be far more worthwhile than a GNU/Hurd iteration.

This is quite appealing: https://wiki.debian.org/Debian_GNU/kFreeBSD_why

Yes, devfs (instead of udev!), OSS (preferable to the ALSA/Pulseaudio mess), pf and jails...

It does seem like Mr and Mrs Devuan meeting for the first time, but before you get too excited...  the arguments presented above in this thread, i.e. that the Linux kernel will somehow get a "hard dependency" on systemd do not have any real substance.  One of the biggest "markets" for Linux is in embedded and particularly Android, which is massive and no systemd there.

The only people tying anyone in to systemd are the distributors (e.g. Debian/Canonical, Arch Linux and of course IBM/Red Hat), the big desktop environments (such as the gnome project) and various projects falling under the freedesktop.org banner.

If you avoid most of that shit, everything just works as before.

However, the FreeBSD kernel is arguably superior and I wouldn't be averse to seeing GNU/kFreeBSD moving over from Debian to Devuan - as it clearly no longer has any kind of place at the former...

As I recall, "Spectre" variant 1 is not mitigated via microcode updates.  Only "Meltdown" and "Spectre" variant 2 are fixable this way.

You also have "TLBleed" and "Foreshadow" to worry about...

If you have doubts, get and build a new kernel from kernel.org.

Proprietary blobs will usually live in the "non-free" repository.  Assuming you have that and "contrib" enabled then you should be able to install Intel microcode (and reboot).

But more Intel flaws just in: https://www.theregister.co.uk/2018/08/1 … ault_bugs/

And you can probably expect more...

Unfortunately, with the exception of tor browser, most browsers are not configured for privacy by default.  The onus is really on you to do that.  Firefox for example is relatively easy to configure to be more secure.  You can even just install tor browser look at what they have done to secure the browser and mimic that in Firefox.

Iridium is pretty much configured as is, to disable chromium's google tracking, but there are still some other privacy settings for you to configure, plus script and/or ad blocking if you want that.

It would be interesting to know what "missing library" was involved?  Usually in Debian based systems it's enough to install the package then

# apt-get -f install

to try to resolve dependencies.

You cannot really be sure anything is "safe" including the software in any given Linux distribution's repositories.

There is always an element of trust - as you, being the end user in most cases, cannot audit the code.

I use Iridium and find it to be 'ok'.  I use it with both the uMatrix and HTTPS everywhere addons installed, but I'm under no illusions that it's 100% private and/or secure.

I believe the Devuan iso images include the proprietary firmware (much like the Debian unofficial iso images).

You're right that script blocking could be seen as security related.  However just completely turning off javascript is probably the best approach, though not practical for most people.

I can manage to browse the web by selectively disabling those scripts which just aren't needed (advertising, tracking, etc related), but the average person usually can't manage this or just doesn't know about.  This is all assuming that 100% of the issue is javascript and nothing more...  you've also no reliable or practical way of knowing which scripts are dangerous and which are not.

Hence "secure by default" is the best approach and why sandboxing, privsep, etc are preferred and very important.

It's not so much "duct tape", as just correctness - in that the OS should never assume that any installed programme is "safe", never mind the web content it accesses.  It really boils down to that the OS should stick to the principle of least privilege.

chromium, like firefox still comes out of the box with google spyware built in and enabled.  chrome is worse still.  Iridium is a chromium fork which does not.  Iridium doesn't seem to be available in Debian repositories, but they do provide a .deb package.  It's available in OpenBSD ports and for Windows, hence why I use it.

Last time I checked, chrome "phones home" when installed initially.  But I wasn't referring to privacy settings or anonymous browsing, etc.

UI wise, I dislike chromium/chrome/iridium, but have gotten used to it.  I preferred the old Netscape/Mozilla/Seamonkey UI, but common sense in UI design seems to be a thing of the past (just look at the gnome project).

I'm not familiar with "process separation".  I am referring to privilege separation (privsep).  It's important for browsers, due to the attack surface offered by modern browsers.  chromium was designed from day one with sanboxing and privsep in mind, where Mozilla have been retrofitting it to legacy Netscape code.

Spoofing user agents is really a privacy thing, rather than a security concern.  For example, you can browse with tor, script blocking and random UAs, but a vulnerability in e.g. the browser, kernel, SSL (or in the CPU!) is still a security hole and could still compromise your system, irrespective of any extra privacy measures you've taken.

There are several user agent switchers for chrome, some offer random switching, but I'm not aware if they have the same functionality as the one you refer to, as I've not used them.

Regarding extensions, I have umatrix (better than what noscript has become by a square mile) and HTTPS everywhere installed.  The extensions situation seems ok, though again extensions always have to be researched an vetted rather than installed blindly.  The Seamonkey extensions situation is far worse...

The Debian package from the vendor breaks the dependency chain.  I hadn't realised that Nvidia provided a Debian package of the blob.  When I last used it, it was a still a shellscript.  Removing it and installing the blob from the repositories should be the first step to resolving this.

Looking at the  cuda version in Debian unstable, it's currently at version 9.1.85, so still older than the vendor version.  The version in the stable release is 8.0.44 - thus you cannot satisfy the 9.2.88 dependency via the repositories.

Run firefox from a terminal emulator and see what output appears?

i965 is part of mesa/dri, it's not the kernel module, so that is in fact correct.

What exactly happens when you install elogind and libpam-elogind as it suggests and try to startx normally, rather than running the older xserver as setuid root??