You are not logged in.
Hello:
... need some level of confidence that I can run headless servers, with unattended upgrades, and not have them break unexpectedly ...
Sure ...
Remember the 21(!) critical vulnerabilities, many of them longstanding ones, lurking within Exim4? (a Debian package)
https://www.theregister.com/2021/05/05/ … exim_mail/
When it was patched/upgraded, every Tom's, Dick & Harry's Exim4 system risked going south without any notice, just like mine did.
Without being noticed for a good while, just like mine.
That happened because on upgrade all previously used scripts were rendered obsolete/useless while at the same time the installer routine advised that the original/existing scripts be kept.
The net result being a totally borked MTA.
https://dev1galaxy.org/viewtopic.php?id=4379
https://lists.exim.org/lurker/message/2 … 4d.en.html
Maybe FreeBSD is the answer after all.
Indeed ....
Maybe (for you, after all) it is the answer you are looking for.
I do not think that Devuan pretends to be the answer for everyone.
In true Linux fashion, I think it is just one answer to the systemd debacle that is slowly and steadily corroding the Linux ecosystem.
I am just a greybeardish (old, actually) user with far too many years of doing tier one/two maintenance of registry run MS OSs to make a living.
To me, Devuan was just what I was needing when systemd started cropping up everywhere I looked.
So here I am.
Now, it is quite evident that your mileage varies.
No problem with that.
That said and with no further comments to make, I'll wish you the best of luck and be on my way.
BTW: thanks for posting the bug report. 8^)
A.
Hello:
... the file '/usr/lib/rsyslog/rsyslog-rotate' installed by rsyslog-8.2302.0-1~bpo11+1devuan1 ...
#!/bin/sh if [ -d /run/systemd/system ]; then systemctl kill -s HUP rsyslog.service fiWhere it should be (and is in rsyslog-8.2102.0-2+devuan3):
#!/bin/sh if [ -d /run/systemd/system ]; then systemctl kill -s HUP rsyslog.service else invoke-rc.d rsyslog rotate > /dev/null fi
Yes.
I've checked and there are two lines missing in the backported /usr/lib/rsyslog/rsyslog-rotate file.
Congratulations!
------------------------------
You have found a bug.
------------------------------
Now, please file a report so it gets fixed.
That said:
Bear in mind that Devuan survives today thanks to a small but very dedicated cast of knowlegeable individuals who devote their time and effort to keep it running.
Doing that, with the resources the Devuan project has at hand, is no small feat.
By any means: it is an endless task.
Unfortunately, as systemd and other assorted crap (eg.: zeigeist) advance and dig their tentacles into the workings of Debian, that task becomes more and more difficult.
It is something most people are not aware of.
-----------------------------------> You seem to be one of them. <-----------------------------------
... please tell me somebody is actually checking packages (and their config files) ...
Indeed ...
There are a few 'somebodies' who sanitise Debian packages for their use in Devuan.
But not nearly enough of them. (see above)
... not the first time this kind of thing has happened ...
I'm sorry to have to break it to you: it is not the first time and it won't be the last.
Please take note of that.
That is how it works with any OS.
Linux is no exception. ie: shit happens
Fortunately, it seldom happens in Devuan.
... and it is seriously eroding my trust in the distribution.
Ahhh ...
I am (very) sorry to hear that.
Really.
Mainly because, if I take you to your word, you will most probably leave the ever growing Devuan user base.
Which is a real pity as Devuan could use another 'somebody', more so if it is one with your bug-tracking skills.
... backports on debian, by contrast, has caused me no grief at all in the last ~20 years.
See above.
If you need the type of trust and assurances that Debian has given/gives you, you may want to consider going back to Debian.
I'm sure they have no bugs (undetected/outstanding/won't-fix) to speak of.
ie: if you don't take systemd into account.
Now: close your eyes, take a deep breath, relax while you have a cuppa while you file the report with Devuan.
You'll feel better afterwards.
Best,
A.
Hello:
... just Debian without systemd ...
... what many old Debian users are awaiting ...
No small feat by any means, an endless task.
Devuan survives today thanks to a small but very dedicated cast of knowlegeable individuals who devote their time and effort to keep it running.
Unfortunately, as systemd and other assorted crap (eg.: zeigeist) advance and dig their tentacles into the workings of Debian, that task becomes more and more difficult.
That is what newcomers are not fully aware of.
Best,
A.
Hello:
... raised legitimate issues in XFCE, but blamed Devuan for those issues, and had a generally poor attitude.
Just to add: I have experienced exactly that type of thing when reporting issues related to windows crashing in XFCE.
As a result, I decided to be rid of XFCE as soon as I can get together my Chimaera/Openbox act.
Best,
A.
Hello:
... an answer for your popping sound.
--- snip ---options snd-hda-intel power_save=0 power_save_controller=N
Exactly ...
That is what keps your sound controller from going to sleep, the pop being caused by the controller waking up, so to speak.
Depending on your hardware, it can get to be quite annoyning.
I don't think the options snd_hda_intel index=1,0 line is related to the pop.
It is probably related to the contents of /proc/asound/cards and /proc/asound/modules.
In my case:
~$ cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xf5ff8000 irq 35
1 [Webcam ]: USB-Audio - Genius Webcam
KYE Systems corp. Genius Webcam at usb-0000:00:1d.7-2, high speed
~$~$ cat /proc/asound/modules
0 snd_hda_intel <- Ultra 24 WS on board sound system
1 snd_usb_audio <- Genius Webcam microphone
~$ Best,
A.
Hello:
I still use the og obmenu.
After all we still use slim.
Quite so, it is yet another reason I am still on Beowulf.
Fortunately (unlike Wicd which is abandoned) it is getting worked on again.
See here.
Kudos and a big Thank You to Robert Pierce for stepping up to save SLiM.
Best,
A.
Hello:
... throttling shouldn't cause video to go off. That's a different issue.
Yes, you are quite right.
But throttling is a feature to protect the CPU from overheating and (eventually) blowing.
So (IMO) throttling must be avoided and that's what a heatsink is for.
In my 3B+ (now unused, a huge dissapointment) the adding of a heatsink to the chip without the speader made an important difference, at least in the comprehensive tests I ran at the time.
Edit: this video may be of use to you, if not there are others.
As always, YMMV.
Best,
A.
Hello:
... gem from 2012:
Indeed ...
"We need free software.
Unless we control the software in the network, the network will in the end control us."
Thanks for that.
Best,
A.
Hello:
Made my day!!
You're welcome.
Don't miss this part:
"... even though I've invested a zillion years in Apple, I'm throwing it away, and I'm going to Linux. To Raspbian, in particular."
Pity it is a systemd distribution.
Best,
A.
Hello:
This up today at ElReg:
https://www.theregister.com/2023/03/17/ … _a_maccie/
Although Thompson is now 80 years old, he most recently worked at Google, where he co-developed Go… although his hiring caused problems: he refused to take the company's mandatory C proficiency test, on the feeble pretext that he designed the C language.
A must read/watch. 8^D
A good week-end to all.
A.
Hello:
... because there's no obvious harm at the moment doesn't mean there isn't some hidden/future problem.
Maybe no even harm, obvious or not.
But *something* left behind that could/may, in conjunction with something else, bring up a problem or a situation that could bring up a problem.
... remembered inotify, which can monitor filesystem use ...
Good idea ...
Please keep us posted.
Thanks for your input.
Best,
A.
Hello:
I'll keep digging.
Please do.
... not hurting anything ...
Not that you know of.
... just annoying now that I know about it.
Indeed ...
I think that what is annoying is that something (unknown to you) is creating a .config dir in /.
And from what I have been told, it should not be happening.
Unless at some time your $HOME was set to /.
Which does not seem to be the case.
Granted, it may not be a big deal, but it should not be happening.
My idea of things like these is that they should be investigated and fixed.
If it is a bug or an oversight, it should be squashed/fixed.
All those "won't fix because it is harmless" issues, warnings and/or bug reports which end up being swept under the rug will are not healthy.
I see it as lousy coding and may (eventually) end up causing issues somewhere in the system.
Of course, YMMV.
Best,
A.
configHello:
... pulseaudio purged, an empty /.cache/ is getting created at each boot.
Not here:
~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ There is no .cache in my /.
All of them live in the /home/user dir.
And this is all the pulse I have:
~$ apt list | grep installed | grep -i pulse*
--- snip ---
debian-pulseaudio-config-override/oldstable,oldstable,now 1.0 all [installed,automatic]
libpulse0/oldstable,now 12.2-4+deb10u1 amd64 [installed,automatic]
libpulse0/oldstable,now 12.2-4+deb10u1 i386 [installed,automatic]
~$ Maybe something else is doing that?
Best,
A.
Hello:
Altoid wrote:..
But then you upgrade the kernel and there it is again.
What I always do is purge apparmor after the upgrade..
A.What about holding the package; sudo apt-mark hold apparmor
or even pinning it ?Would the upgrade still go through ?
Hmm ...
No idea.
Have not tried it but I don't see (?) why it shouldn't.
Yes, I guess I could pin it.
ie: the same way I do with pulseaudio and see what happens on the next upgrade.
Bear in mind that there are other apparmor related libraries which are/may be needed by other packages.
eg: libapparmor1
~$ aptitude why libapparmor1
i stress-ng Depends libapparmor1 (>= 2.10)
~$ Edit:
It seems that there's more than stress-ng involved with libapparmor1.
~$ aptitude why libapparmor1
i slim Depends dbus
i A dbus Depends libapparmor1 (>= 2.8.94)
~$---> Very strange all this did not show up on my previous query to aptitude. <---
I have not used stress-ng in years, so I might as well get rid of it. and solve the issue.
We'll see how the pinning goes.
Best,
A.
Hello:
... strongly suspect we're going to need something like daemon ...
... as systemd user-units become more popular. continues to extend its tentacles further and further into Linux. <--- reads better now, I think.
... this /.config and /.cache garbage is created on chimera ...
Not only on chimaera.
I run Devuan Beowulf with a backported kernel.
I suspect it was there since ascii but can't confirm.
... but not remove them if they exist ...
... not tracked by dpkg (for extra nastiness).
So I have seen.
... absolutely consider this a bug to be fixed.
Probably to be reported to Debian.
Don't think it's a Devuan thing, but ...
... has to do with pulse assuming systemd and doing broken things ...
... if that is so, it could/may be due to an incomplete/faulty sanitisation of the pulseaudio package by the Devuan devs.
Thanks for your input.
Best,
A.
Hello:
... ditch pulseaudio on my destop.
Yes, but do remember to check the link I posted.
You don't want pulseaudio pulled in again by some uncouth package.
~$ cat /etc/apt/preferences.d/avoid_pulseaudio
Package: pulseaudio:*
Pin: version *
Pin-Priority: -1
~$ Best,
A.
Hello:
... only where pulseaudio is involved.
... janky behaviour for potteringware ...
... extremely ugly.
Ah ...
... could still be a bug in pulseaudio ...
Could well be.
No matter, quite easy to fix.
First this:
# apt purge pulseaudio && apt autoclean && apt autoremoveAnd then this.
Best,
A.
Edit:
Out or curiosity (I purged pulseaudio two/three years ago) I went to see what was up in my / dir.
Seems that purging pulseaudio is not enough: I found /.config/pulse and within it, two files.
One was a 26a708d3d7dc6778fc6ff9f55921b024-runtime file and the other was a cookie file and they were not size nought.
So I left the /.config dir (don't know if it is needed), but eliminated its contents.
Hello:
The last time I updated my Nvidia drivers was probably before moving from beowulf to chimaera ...
Some Nvidia cards can no longer be used in Linux systems as Nvidia dropped support for them.
In my specific case, the 340.108 driver I use for my two perfectly working FX580 cards.
That is the main reason I am still on Devuan Beowulf running a backported kernel till I am forced to move on and use the Nouveau drivers.
Hopefully, they may work better than the last time I tried them.
You may want to have a read here and see if you find the answer you are looking for.
Best,
A.
Hello:
... figured it was some form of operator error ...
So ...
It's a bug in the grub installer?
Best,
A.
Hello:
... "missing grub binaries" were just a path issue, had to do "su -" to get proper roots path ...
This has been so since the Beowulf release:
### What's new in this release
--- snip ---
Changes in su
- The behavior of su has changed. Use 'su -' to get root's path or use
the full path to commands if you use only 'su'.
- There are several ways to get the old behavior. The easiest is to
edit /etc/default/su to add the line:ALWAYS_SET_PATH yes
See the following for more information:
https://www.debian.org/releases/buster/ … -variables
https://wiki.debian.org/NewInBuster
https://bugs.debian.org/cgi-bin/bugrepo … bug=905564
... the grub installation "appears" broken, as the usual grub binaries and scripts are mia-- i.e no "grub-install" "grub-mkconfig" etc.
Could this be a bug?
The grub installer seems to ignore the new su behaviour as described in https://files.devuan.org/devuan_beowulf … _notes.txt.
Not running an efi box, so can't say much more about this.
Best,
A.
Hello:
Haven't come across this but ...
I don't think there's any magic or wonder of any sort going on here.
The fact that lsusb does not show the connected device only means that.
ie: that it does not show/detect it.
But it does not mean that the SP Flash Tool cannot read the processor information belonging to the Android device.
ie: after all, it is the SP Flash Tool app that is doing the reading.
The thing is that (from what you are saying) the only place the SP Flash Tool can check the processor data is on the Android device.
And the only way the SP Flash Tool can do that is through the USB connection you established by plugging in the device.
That is, unless I am missing some new and recently develped tech.
Best,
A.
Hello:
... but it's not in the repos?
LibreWolf is not in the Debian repositories and as a direct consequence, you will not find it in the Devuan repositories.
Now ...
Why is it not in the Debian repository?
No idea ...
Maybe for the same reason a number of other distributions don't don't have it in theirs.
But I don't know what that reason is.
Best,
A.
Hello:
... plenty of laptop vendors selling corebooted Linux laptops ...
I have not been into laptops/portables for for over 15 years now.
For me, they ended up being rather expensive propositions with a very limited lifespan and nought repair possibilities.
ie: in comparison to all other hardware I have owned.
... if you want a desktop, you can just build your own ...
That's what I did for many years till I purchased the box I have now and upgraded it to its full potential.
It's a Sun Microsystems Ultra 24 WS purchased in late 2015, second hand with ~ 4 years' use but in mint condition.
Like you point out, this is a WinTel thing, which obviously includes AMD and it will continue as it has been a very profitable business model for all involved.
The thing is that I don't see where to look for an aternative board/processor for this nice box.
And as the article I linked to makes blindingly obvious, the systemd virus is expanding more and more each day.
Thanks for your input.
Best,
A.