You're being slightly 'diplomatic' there to say the least.

A ban can be permanent or for days/weeks/months/years - it's purely a matter of nomenclature...  a ban is a ban regardless of the term imposed, be it a day or a lifetime.  You can call it a "suspension" if you like.  In the same way that a permanent ban could be termed an "indefinite suspension".

Just use the distribution agnostic method for now:

https://wireless.wiki.kernel.org/en/use … i#firmware

Oh dear...

Some people should at least stick to software ideologies.

As you know, I'm not a Devuan user (or a Debian or Linux user) and you've known my opinions on this project from day one (so once again, thank you for tolerating my continued presence), but any project founded on "anti" sentiment is pretty much doomed from the start.  This forum seems to be keeping it technical, it's getting it right thus far, it surprises me that such crap is being posted on the mailing lists...

Political and ideological opinions mean absolutely nothing in the world of software development.  The person who made your morning coffee could be racist, xenophobic and homophobic - it's in their head and there's actually fuck all you can do about it.  Hans Reiser killed his wife, so some people don't use his FS.  You have no idea about the beliefs of the rest of the developers of any given FOSS code / OS - however extreme they may be (my personal worry has always been that there may be a few Elton John fans in the mix, sneaking references into the code here and there...).

You'll also find that more than 50% of Linux fans are clueless when it comes to the origins of free software, the ideology of FSF/RMS and the permissive approach as pioneered by UC Berkeley.  They will rant and foam at the mouth at having one piece of Poettering crap installed, while not necessarily knowing where the rest of the software comes from, whether it's "good code", who developed it and to what end.

The birth of systemd has all come about on RMS' watch.  It's yet more freedesktop.org shite, which sets out to emulate "what Apple are doing" or "what MS are doing".  The Linux foundation sold out to fortune 500 companies years ago, every bit of work done there is at the behest of IBM, Alphabet, HP, Oracle, et al and now even MS have joined in the gang bang.

Red Hat developed systemd, because they're in the business of enterprise support and what better way to secure that business model than to create that which has to be supported from scratch?  MS made a business out of this for decades as have others, it's nothing new.

Distributions adopted it, because those pushing it gained sufficient "mind share".  Amazingly developers, supposedly smart people, were convinced that a large mass of complex and poorly written code is the answer to everything.  Because it's so widely accepted, the fallacy of popularity comes into play.  systemd "works".  I have to use MS Windows for a living and I can assure you that "it works".  But systemd works for those that want the functionality it provides.  People are fickle and it's easy to cater for laziness or inability and a need for convenience.  At a certain point when those are in abundance, code correctness, simplicity, robustness - and above all security goes out the window - mainly because it's making somebody somewhere's life (job) a lot easier (for now).

In a distance future the cycle will begin anew and the replacement for systemd/Linux will be born, as GNU and Linux were.

GPL's code can't be just closed off and re-purposed, RMS put a lot of time and energy into that, but it's developers can be bought off, put on the payroll or just convinced and that's what has happened - over the last two decades.  The developers can also write bad code, code which doesn't follow "UNIX Philosophy", isn't POSIX compliant, mainly because someone will convince someone else that all of that has gone out of fashion.

But when all is said and done, software development is about doing...  whining on a mailing list won't achieve anything good.  Personally if I didn't like an OS and if I had the choice, I would just stop using it.  As someone once said: "shut up and hack".

BSD, GNU, Linux and other FOSS projects used to all about "by hackers for hackers" - for Linux and associated projects, all of that is past.  The gulf between the developer and the user has widened to the extent that, to Linux users, contacting a developer is unthinkable (and in certain cases - not possible).

There is a huge difference however in *BSD land.  For example, I had a short but interesting exchange with a well known developer (of OpenBSD) some years ago while (unsuccessfully) trying to resolve a device driver problem.  It was an enlightening experience.

In *BSD land emailing the developer is the norm, conversing with developers on the mailing lists is the norm.  Doing it yourself is the norm.

In Linux land, complaining and whining and posting "me too" against every bug report is the norm.  Complaining that Linux distro abc doesn't do what you want it to do is the norm, complaining that Linux distro x is not the same as Linux distro y is the norm.  In fact posting all manner of noise and very little signal is now, very much, the norm.

Great trolling!

Maybe missing dbus "plumbing"...  probably an error you can safely ignore?  (as with most of the crap gtk spits out)

https://packages.debian.org/source/jessie/at-spi2-atk

You could try installing "libatk-adaptor" (the only other relevant binary built from that source package) and see if that "silences" it...

The problem with that approach is that the binary is not built for the target system and dependencies have moved on, become obsolete, etc (for that particular package there are quite a few examples).  Generally with any Debian system (or system based on Debian), stable freezes and testing/unstable diverges further and further away.  So you may get away with this early on in a stable release, but it's less likely 12 months later.

You may on occasion be able to install one local package (via dpkg), with few dependencies, which are already satisfied by the installed distribution, but adding another distribution's repositories is a bad idea, as you can end up with half of that distribution installed or worse still find yourself in a situation where an "accidental" (broken) upgrade has occurred.

Even with a good knowledge of apt pinning, setting default release, disabling automatic upgrades, etc, it's still a bad idea, unless you're running a mixed testing/unstable system and know exactly what you're doing.

In terms of clock speed it's not actually that huge a difference.  Apparently that core is 3.4GHz and can overclock to 3.9GHz, which I assume you have?

Usually modern CPUs don't run full belt 100% of the time.  They use "dynamic frequency scaling" to increase clock speed on demand.  Also unless you're running tasks which make heavy use of multi-threaded programmes you're not going to see a huge difference if you're just browsing or word processing, etc.

Linux uses the procfs filesystem, you could grep /proc/cpuinfo to see what MHz you're running at?

Then put the system under load, e.g. compile something (such as a new kernel?) with a parallel build (number of jobs = 1.5x the number of cores).

grep /proc/cpuinfo again to see if the clock speed has increased.

As I recall, with modern Intel CPU's, it's all configured via the BIOS... so the frequency scaling should be turned on there (forgot the Intel "brand names" for these) and Linux cpufreq driver isn't needed.

# apt-get update && apt-get upgrade

?

You can always grab the source and build a new kernel.

The "spectre" "fix" isn't so simple I suggest reading at least the white papers at the sites set up for these.

It's not (usually) a file system thing, so I'd imagine you have some kind of 'indexing service' running?  Without more details, it's going to be difficult to say.  If it's something which starts with a particular desktop you're running, just disable it.

udev is part of the systemd source tree - it's a systemd component.  This wasn't always the case, but since around 2012 (?) it is now.

It has zero to do with "network manager".

Device nodes are generated dynamically at boot by udev.  This is one of the much vaunted "features".

You can, or could, still just revert to a static /dev, make all your device nodes and just bin udev altogether.  Though, it's a use case thing - horses for courses, etc.  (Full blown desktops, won't like it...)

Alternatives to udev, you'd probably have to port over and build from source yourself.

If you pass 'net.ifnames=0' to the kernel command line it will disable the "predictable" network interface device node naming. i.e it will return to the old eth0, eth1... naming.

It will not solve the OP's problem of persistent naming.  That used to be resolved by clearing /etc/udev/rules.d/70-persistent-net.rules (in this case it would need to be run on every shutdown).

Combining the two approaches should give the desired result ("eth0" as the sole network interface).

however this is actually systemd we're talking about, so it's a moving target.  What works now, may no longer work in 6 months' time.

It's probably more advisable to switch away from systemd/udev and invest time in learning the alternatives...

More details of the mess here: https://www.freedesktop.org/wiki/Softwa … faceNames/

(read it and weep)