You are not logged in.
Hello:
... two monitors with nouveau.
Up to four (maybe more? if your card/s have the outputs/memory.
I use three 19" monitors @1280*1024 (3840*1024 desktop) fed from a pair of Nvidia Quadro FX 580 cards.
$ xrandr
Screen 0: minimum 320 x 200, current 3840 x 1024, maximum 8192 x 8192
--- snip ---
$For a short time installed a fourth 15" monitor just to see if/how it worked, took it down for lack of space.
No serious problems save some artifacts in the centre monitor which the Nvidia driver did not have.
@greenjeans
... don't miss flailing about in xorg.conf ...
Yes, it was a hassle.
But once you got it down pat, it worked perfectly well.
To wit:
Once I managed to write up a properly working xorg.conf for the first Linux distribution I tried, first with two and then with three monitors (cannot recall which) it was just a question of transplanting it to all the other distributions I tried out without having to touch it: it just worked® in all of them, including my first Devuan (Jesse) and so on with Devuan till the demise of the 340XX driver in Chimaera.
The only problem I see with nouveau is that it seems impossible to see under the hood, so to speak.
ie: just what is the layout of the xorg.conf file I am using now?
That should not be so as the configuration file, if it exists, gets priority.
Best,
A.
Hello:
Why is the Realtek RTL8812AU chipset such an orphan in the Linux world?
Who knows?
Maybe some chipsets are prettier/shinier than others?
Not the first and won't be the last.
See here: https://github.com/morrownr/8812au-20210820
Maybe there's some useful information for you.
Best,
A.
Hello:
I once had a question about this.
TL;DR
It seems that, using nouveau, you do have to have firmware-nvidia-graphics installed, whether you need it or not.
Otherwise you get some bitching in dmesg.
ie: if you use nouveau but your specific Nvidia hardware is not on that list (~4.5mmb on disk), you obviously do not need those firmware files in your system.
No idea why the nouveau driver looks for firmware it clearly does not need.
Is it not aware of the installed hardware to check against the supported cards that need firmware?
See here: https://dev1galaxy.org/viewtopic.php?pid=51169#p51169
Best,
A.
Hello:
... you could also block KeyPassXC from accessing the network ...
I already do that by simply not installing it in my box. 8^P
^^^ Just taking the piss ...
On a more serious note:
My take (common sense approach from a desktop user, if you will?) is that keypassXC requiring network access is a big no.
It gets a larger no when it turns out that it is required by default. (no, the "optional and opt-in" bit does not satisfy me at all.
ie: the code is still there)
It then gets the largest possible NO when I read the justification for the default network access:
KeePassXC needs network access for downloading website icons (favicons) for password entries.
Because favicons are an essential and inseparable part of the keypassXC experience, right?
Of course, YMMV.
Thanks for your input.
Best,
A.
Hello:
Password managers might be very attractive targets to compromise.
Hmm ...
Password managers might be are very attractive targets to compromise.
There you go.
Best,
A.
Hello:
Should I be concerned ...
As you may have read in this thread, installing keypassXC requires network access by default.
If you want keypassXC without any networking code, you have to compile it yourself.
KeePassXC needs network access for downloading website icons (favicons) for password entries.
Now ...
If website icons are so important to you that giving keypassXC network access to get them is not a problem, then you should not be concerned. 8^°
Best,
A.
Hello:
... media itself it good (containing a Devuan Full.iso installer)
Not the right media to use for a test unless you are absolutely certain than you can read it in any other drive.
Consider using an OEM written media to test the drive.
Have you checked the dmesg printouts?
A.
Hello:
"Systemd but we support exploring alternatives"
Nothing but a blatant lie.
A.
Hello:
... drive itself is recognized ...
From the linked screen capture, it would seem that the hardware is working.
Just in case, boot the box without the optical drive plugged in, plug it in and check the dmesg printout.
If the drive is correctly recognised by the system and no errors are reported, it would mean that it is not a Devuan issue.
If the drive is working properly, the problem would lie either with the media or with the laser optic itself.
Check with a known/working factory stamped (readable) CR-ROM or DVD to rule out the media being bad.
Q: can you hear the drive spin when you load a DC/DVD? What does the dmesg printout say?
If the problem is the laser optic, it may come down to something as simple as a dirty lens or a more complicated issue like eg: a damaged laser assembly or a power problem*.
... would recognize any media?
A properly working drive should recognise the media it was designed for.
Check here for the manual and specs for that drive (SH-S162L?).
https://samsung.manymanuals.com/optical … nual-14158 <- see page #32 of the manual
Best,
A.
* From a a fast look at the manual, it would seem that the drive is an internal ATA/ATAPI (E-IDE) model (?). ie: needs both 12v and 5v power.
It could be that whatever adapter you are using is not providing enough power for the laser to read properly.
Hello:
... in my dmesg there's nothing about microcode until line 488 ...
Well ...
Could be that ... (No idea, just shots in the dark. 8^°)
1. it is an AMD processor. ie: not Intel
2. it is much newer than my Q9550 (released Q1/2008)
3. my CPU gets updated early to a revision number while yours gets the same type of update but to a new patch_level
Note the date on the microcode file (revision 0xa0b, date = 2010-09-28 - 15 years ago) while your patch level is not dated.
Q: do you have the amd64-microcode/stable 3.20240820.1~deb12u1 package installed?
Best,
A.
Hello:
After installing the microcode package ...
These are the first two lines in my dmesg printout:
$ sudo dmesg | more
groucho@devuan:~$ sudo dmesg
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
[ 0.000000] Linux version 6.1.0-38-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14+deb12u1) ...
--- snip ---
$ie: first the microcode and then the kernel
Further on, I get this:
$ sudo dmesg | more
--- snip ---
[ 0.155960] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
--- snip ---
[ 3.399828] microcode: sig=0x1067a, pf=0x10, revision=0xa0b
[ 3.400056] microcode: Microcode Update Driver: v2.2.
--- snip ---
$ I also have the intel-microcode package installed and the module blacklisted in /etc/modprobe.d.
$ apt list | grep installed | grep intel-microcode
--- snip ---
intel-microcode/stable-security,now 3.20250512.1~deb12u1 amd64 [installed]
$ The directory /lib/firmware/intel-ucode has 125 files in it, all with a Modify time = May 18 20:06, so they receive updates.
Some insight from Intel:
OS vendors may choose to provide an MCU that the kernel can consume for early loading. For example, Linux can apply an MCU very early in the kernel boot sequence. In situations where a BIOS update isn't available, early loading is the next best alternative to updating processor microcode. Microcode states are reset on a power reset, hence its required that the MCU be loaded every time during boot process.
I'd say that the module is blacklisted so that only the kernel deals with the respective microcode file at the very start of the boot process.
Just an edguess.
Best,
A.
Hello:
... if anyone out there had experimented with the various recipes ...
FYI, if interested, See here.
Interesting, but probably not worth all the hassle and risks involved.
-> Should I keep the source?
Yes, you will have to recompile the driver once in a while.
Some day the Debian team will deprecate these drivers and delete the source from the servers. < ######
Then you will have hard time finding the source elsewhere.-> How often should I recompile the driver?
I don't know the exact answer but I have few assumptions.Every time any of the dependencies is updated.
Every time GCC is updated.
If the driver stops working.
If dkms fails.
As always, YMMV.
Best,
A.
Hello:
... ceres, would that mean "excalibur" ...
Not so fast. 8^°
The current status of the Devuan releases can be seen here.
As you can see, the stable/maintained releases are these:
Daedalus / Bookworm
Chimaera / Bullseye
The archived releases are these:
Beowulf / Buster
ASCII / Stretch
Jessie / Jessie
The next* Devuan release, Excalibur (Trixie) is still in the developement / testing phase and has not been released yet.
* as always, it will be ready when it is ready.
Last but not least, there is Ceres, Devuan unstable (Sid).
It has not and will not ever (?) be a release as we know it.
It is a platform for experimentation which is why you have a 340XX package available.
As for the nvidia-legacy-340xx-driver, it is still available for Beowulf but not for Daedalus or Excalibur.
It has been so for a good while now and I have serious doubts as to its viability in future releases.
I asked (previous post) to see if anyone out there had experimented with the various recipes for installing that are making the rounds in the web lately.
Best,
A.
Hello:
Just checked ...
Hmm ...
Now it is working for me also.
It was down (for my end) for at least 10',
... a glitch ...
Most probably.
Best,
A.
Hello:
Just a heads-up ...
As of just a few minutes ago, the Devuan package information page https://pkginfo.devuan.org/ issues a 504 Gateway Time-out reply.
ping and traceroute seem to be correct.
# ping pkginfo.devuan.org
PING www.devuan.org (116.202.138.214) 56(84) bytes of data.
64 bytes from www.devuan.org (116.202.138.214): icmp_seq=1 ttl=46 time=249 ms
64 bytes from www.devuan.org (116.202.138.214): icmp_seq=2 ttl=46 time=249 ms
--- snip ---
## traceroute pkginfo.devuan.org
traceroute to pkginfo.devuan.org (116.202.138.214), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.454 ms 0.557 ms 0.682 ms
--- snip ---
19 ex9k1.dc1.nbg1.hetzner.com (213.239.203.222) 232.639 ms ex9k1.dc1.nbg1.hetzner.com (213.239.203.226) 240.921 ms ex9k1.dc1.nbg1.hetzner.com (213.239.203.222) 231.255 ms
20 www.devuan.org (116.202.138.214) 248.996 ms bonito.devuan.org (85.10.193.185) 245.106 ms 244.119 ms
# Best,
A.
Hello:
... so difficult to recompile it?
For someone who knows zilch about any and all of that, the answer is, a definitive 'yes'.
It is both much easier and reassuring for me to simply avoid using keypassXC.
I am quite sure a great many Linux users think along the same lines.
Because ...
You know, "it might be a sort of spyware".
If it is about security, you have to compile it yourself.
Right ...
Well ...
That is but one way of looking at it.
If it were the only way, inherently trusted distributions and repsitories (Like Devuan Linux and others) would not even exist.
As always, YMMV.
A.
Hello:
... tell the people who are making the keypassXC to remove dbus ...
Or to package it without any networking code.
ie:
Not optional
Not opt-in
Just no network access code.
KeePassXC needs network access for downloading website icons (favicons) for password entries.
Right ...
A very important and absolutely essential feature, eh?
What would I ever do without my lovely favicons? 8^°
A huge red flag for me.
As always, YMMV.
A.
Hello:
... why I seem a little "slow" ...
I cannot imagine why you would seem slow.
Your questions were clear enough for everyone to know what you were asking about.
... remember what I had for lunch.
Most times I can't, even if I cook it myself. 8^°
No big deal.
... grateful that people here ...
All part of the Devuan team.
... why it felt like Mozilla was pressuring me ...
Probably because that is exactly what they were doing.
Glad you were able to get things sorted.
Best,
A.
Hello:
... email journey/saga starts at aol and ends at claws-mail
Yes, it can be trying.
Fortunately I found my email client (in another life running W3.10 and the rest of them) after trying out a couple which did not make an impression on me.
I cannot recall the exact names but I'm sure one was called Eudora.
Never keen on any sort of webmail or IMAP, Pegasus Mail ended up being my email client for the last 26 years or so.
While not FOSS, it has always been free and community support has always been great.
Never let me down.
Being able to run it under Linux via WINE was the deal breaker in my definitive move to Linux back in late 2013 (?)
Best,
A.
Hello:
... this laptop does not sport a parallel port, if am not mistaken.
If it is not visible, it does not.
ie: a DB25F is a bulky thing. 8^)
My workstation does not have visible DBxx ports (male or female), but there is an available header on the MB and a BIOS setting to activate a serial port.
I doubt that is the case with your laptop.
Now, even though there is no parallel port available to Linux, the line printer module (lp) is loaded at boot time, probably (?) by CUPS and as a result, the other printer modules. eg: parport, ppdev and parport_pc.
You could check with dmesg and lsmod to see if they are being loaded by any other software and eventually blacklist them if they are not needed.
Best,
A.
Hello:
Where is the DEVUAN Thunderbird 142 package ...
As you surely know, Devuan packages come (basically) from the Debian repositories, unless they are in need of systemd sanitation, task performed by our (few and tireless) Devuan maintainers.
If for [reasons] that is not possible, the package in question is banned from the Devuan repositories, keeping things on the up&up , so to speak.
ie: our distribution in a healthy state. 8^°
This means that for a package to appear in the Devuan repositories, it first has to appear in the Debian repositories.
The latest Thunderbird package available in the Debian repositories (stable/Trixie) is 1:128.14.0esr-1~deb13u1.
See https://packages.debian.org/search?mode … hunderbird
As Devuan Excalibur is still in its development phase, the latest Thunderbird package available in the Devuan repositories (stable/Daedalus) is 1:128.14.0esr-1~deb12u1.
See https://pkginfo.devuan.org/cgi-bin/poli … d&x=submit
When Excalibur gets released as stable, the latest Thunderbird package available will be the same one as the one in the Debian repositories.
Scroll down this search page ...
I'm afraid you missed an important bit:
Auto-generated based on listed sources. May contain inaccuracies.
TL;DR
If you don't see a package in the Debian repository, you will not see it in the Devuan repository.
If you see it in the Debian repository and not in the Devuan repository, it is because it has been banned due to unfixable systemd dependencies.
And that is most probably the reason why no one is talking about this subject.
Best,
A.
Hello:
Credit to golinux for first posting of the link ...
Indeed ...
And then, there's also this bit:
## Old Business
- Debian Trixie has been released
- And what a cluster-f*** it is!
Right on the dot. 8^)
Best,
A.
Hello:
Every single one of these projects requires ...
Very interesting post, never thought about it in monetary terms.
With more or less the same idea in mind, I've been posting about that for a few years now and the usual reply is "if you don't like it, why don't you blah, blah blah ...", obviously missing the point by millions of miles.
TL;DR
It seems that it's not possible (and probably won't ever be) to harness the creative work of the countless thousands of programmers, developers and contributors dedicated to this fantastic project started by Linus Torvalds in a way that that they just work together and come up with just 'one' 100% functional and scalable 'distro' instead of generating gadzillionz different flavours, forks of whatever is available out there.
One of the (few) negatives of open source and free licensing is that forking projects just for the sake of having their own project - "look Ma! I rolled my own distro!!!!" - has almost become the norm.
It is highly counter-productive and there is no logical reason for it.
Best,
A.
Hello:
... systemd and wayland are contingencies in preparation for the actual future of corporate Linux ...
Quite so.
And then, Devuan (and every other distribution built on it) will be toast.
Debian (fundamentally, the ecosystem* behind it) knows this because it is, for the most part, the path / timeline they have traced from the start.
Eventually, Debian (at least as we know it today) will also cease to exist and be replaced with whatever it is they eventually come up with.* MS, RH, IBM, Alphabet, etc.
The next step, already in motion, is this cross-distro unification idea.
And when that has become the norm, the question they will be asking will be "why do we have so many distributions?", the answer being quite obvious:Why not have just The One OS for everyone, much easier to maintain.
And control.Imagine, even a simple AI will be able to do it. 8^°
It is not a prophecy or any such thing, the writing has been on the wall for the longest time.
Way before Poettering's 2010 screed.
Best,
A.