Hello:

See my reply to Majorie.

I had to do that in my 1000HE.
Removed the updated version that screwed things up (102.x), installed 91.x and then pinned it.

To be honest, I am (rather) relieved to see I am not the only person affected by whatever Mozilla is doing lately.

I was beginning to think it was my recursive DNS Pi-Hole / UBlock Origin generating these issues.
But no, they seem to be working perfectly well.

Two FFs in my box is far too much FF for me.
If we're not carefull, they may spawn a litter.

But ...
Just who is in charge at Mozilla? --> DH Supremo Poettering?  8^/

I think I'll cut my losses and do my home banking with the LibreWolf 102.01 AppImage for the time being.
At least the banks seem to be OK with it, no issues whatsoever.

And I can get to see maps/bus routes without having to jump through hoops.

Thanks for your input.

Best,

A.

Hello:

I have many times thought about the possibility/convenience/need of doing such a thing but always came up, for some reason or other, short of arguments.
Not that I did not have enough of them, what I did not and do not have is previous experience or time.

I also adhere to the if it works, leave it be philosophy.
But being a stubborn tinkerer, I have a rather bad track record on that account.

My box is a Sun MS Ultra 24 WS with an Intel Q9550+16Gb RAM, SLI SAS1068E SAS controller and a pair of Nvidia Quadro FX580 cards to drive three 19" monitors, two of them Samsung SyncMaster 940N. There is also an Adaptec 2940UW SCSI controller for my Umax S-6E scanner and a PCIe USB 3.0 PCIe card.

All the hardware listed above is ranked as old or ancient (depending on who is talking) but my take is that if it works as expected, it is neither old nor ancient.
Look at the Voyager probe ...

That said, I expect that save some event that kills the mb, I should not need to undertake any hardware upgrading, save maybe the SAS controller and drives which are SAS-1/3.0 Gbit/s a couple of years from now when I can justify getting that hardware because of a good bargain.

But I see that at some point in the future, an always fast approaching horizon in IT, it may be a good idea to churn out a slimmed down/monolithic/dedicated kernel for my box, with just what its hardware needs to run.

My main doubt with respect to that is the eventual updating/upgrading of the kernel.

How does that work? Does the kernel have to be compiled everytime?

I'd appreciate some insight into this aspect of the kernel building issue.

Thanks in advance.

Best,

A.

Hello:

Magic? *

Nonsense.
No such thing at work in your Ideapad when running on Ubuntu or Mint.

There is something that Ubuntu/Mint loads that makes those Fx keys work as F100e keys.
ie: not in their default function or otherwise mapped function.

Look in dmesg or in the Xorg log, it has to show up somewhere.

See if you can search/ask at the Ubuntu/Mint fora.
eg: seach for "Lenovo Ideapad 100e F-keys not working" and maybe you'll get a lead as to what it is.

Like I mentioned, my Asus 1000HE required a driver to be loaded for F1 to F12 to do something else (Fn+Fx) to work.
Otherwise they acted as regular F keys.

That said, maybe there is some key combination you have to press to "come and go" from regular F-key function to special F-key function.

Check that you are enabling the BIOS setting properly.

* Magic
What Devuan devs/packagers/maintainers and admins do to keep the Devuan project alive and running.

Best,

A.

Hello:

You're welcome.

To say the least.

I meant solved for the OP who (because of Distrowatch) thought Unstable and Testing used systemd.
That was cleared up and ceased to be an issue for him.

On the other hand, what was not cleared up and you seem to have cracked, is the why Distrowatch has the wrong data or at the very least, misinterprets the available data, something which was beyond my intent.

And therein lies the lack of basic common sense / bad attitude from the chap at Distrowatch.

Devuan (let's accept that it was Devuan, just for argument's sake) is explaining that Unstable and Testing do not have/use systemd, that all those files are shims to be able to use some packages from the Debian repositories.

But no, they dig in deeper, wriggling their way out the argument and insisting.

Wouldn't it have been much more reasonable for them to have sent an email to the address I provided and simply ask?
Our dedicated Devuan devs would have asked about the source of their data and promptly cleared up the problem for them.

But no, no - can - do - that.

Not a problem, to me Distrowatch was never a place to go for distribution information.
It is just a long list of names.

Thank you for your input.

Best,

A.

Hello:

I would not be too sure about that.
ie: the "supported" and "it doesn't matter if it is installed by default" parts.

Some time ago there was a thread related to timeshift with a LUKS / btrfs combination and how it worked properly in Debian and not in Devuan.

After a long exchange of ideas here at Dev1, a bug was reported to Debian by the OP.

Quite obviously, Devuan was not mentioned.

The bug was reported to because timeshift (with the LUKS / btrfs combination) worked perfectly well with Debian+systemd but not with Debian+sysvinit.

If interested, see bug #1034328

The answer from Debian?

Best,

A.

Hello:

Yes, not exactly but closely related to systemd.

Xorg uses elogind to keep it from running as root.
Something which has always (rightly so) been a source of stern criticism.

See this post at the Artix forum for a quick explanation.

I think this thread can be marked as solved.

Best,

A.

Hello:

The only reference to cgroups I have in /run/systemd is cgroups-agent, a Unix socket.

Location: /run/systemd
File type: socket
Total size of files: 0 bytes
Size on disk: 0 bytes

And then there's /lib/elogind/elogind-cgroups-agent which is a shared library.
I don't use Network Manager, my system uses Wicd.

From what I understand from the netstat-an printout, cgroups-agent is an active UNIX domain type socket with two attached processes, no 'Flags' data,  used in DGRAM (connectionless) state.
ie: not waiting for a connect request, connected or listening

Proto    unix
RefCnt   2     <-- attached processes
Flags    [  ]  <-- no flags - not waiting for a connect request   
Type     DGRAM <-- connectionless
State          <-- empty - not connected to another socket
I-Node   15845
Path     /run/systemd/cgroups-agent

My guess is that it is needed for some systemd-less reason (elogind?), otherwise it would not be there, but that's all I can say.
It is all rather over my head.

That said,a couple of questions pop-up:

- what does/would it take for the cgroups-agent socket lose its connectionless mode/state?
- what can be done to avoid that from ever happening? ie: some way to block/blacklist it

Thanks in advance.

Best,

A.

Hello:

Thanks.

Best,

A.

Hello:

Not on any Devuan team, not a dev/maintainer/packager either.
Nevertheless, I sent the people at Distrowatch an email.

--- snip ---

... Devuan does *not* use systemd as its init software in *any* of its versions/releases.
Devuan is Debian *without* systemd.

You may want to consider fixing that as it can lead to confusion.
Thanks in advance

--- snip ---

Here's their reply:
---

Devuan does not ship systemd as the _default_ init system. It still
includes the package in its repositories, which is what we show in our
package table.

---

Right ...

Then I wrote back with a link to the Devuan Package Information page with a query* for the systemd package and an email** address where they could write and ask for confirmation to what I was saying, I got this (interesting) reply:

---

The systemd packages are not only in the repositories, you can see them
on the Devuan package query page here:

https://pkginfo.devuan.org/cgi-bin/poli … *&x=submit

As you can see, our information is correct and systemd is in the main
Devuan repositories.

---
* https://pkginfo.devuan.org/cgi-bin/poli … d&x=submit
** freedom at devuan.org

I was about to write back with an explanation about the difference between the systemd package and all those files/packages named abc-systemd, systemd-xyz, abc-systemd-xyz (and so on) but decided that it was really not worth the effort.

But that's on me, I've never suffered fools lightly and too old to start now.

That said, I have not seen/found which page of the Repology site says anything about Devuan and systemd so I did not address the matter with them.

Best,

A.

Hello:

I see that both Unstable and Testing have OpenRC, runit, SysV under "Feature" -> "Init Software".
systemd is not a listed option.

That said, I also see it is listed as in the "Package" column but systemd is not an available package in the Devuan repositories.

There would seem to be a discrepancy in the Distrowatch page.
Either that or, being Testing/Unstable releases, the package is there as a place holder and not used.
Not a dev/maintainer so I cannot say much more.

Have you tried setting up "Testing" or "Unstable" to check is systemd is effectively used?

Best,

A.