You are not logged in.
Hello:
... Microsoft pushing even far ...
So ...
How is that a surprise?
ie: to you or anyone else
... real problem are ...
+1
Best,
A.
Hello:
... anyone uses Mintstick ...
I don't use mintstick, last time I ran Mint was ~ 8 years ago.
It but I downloaded the cmd line version from the Devuan repository and installed it.
Drags along gir1.2-polkit-1.0 gir1.2-udisks-2.0 gir1.2-xapp-1.0 python3-gnupg python3-parted
Q: does it work better than dd?
You may recall I had a series of issues when I tried to dd an *.iso file to a 4Gb SD card/8Gb USB stick to use in my (non UEFI box) not long ago.
Had to jump through a lot of hoops to get it done. See here.
If you post instructions I can give mintstick a try then run your script and report.
ie: only a 64Gb stick available for testing.
Best,
A.
Hello:
@greenjeans
... so win/win.
Likewise.
(Shit, man ... made me blush.)
@golinux
... radical change ...
... applications like the DE
I'm quite aware of the implications re: Devuan being Debian without systemd.
[OT]
But I don't think that is a long lasting status quo.
The weave that keeps it in place is permanently being pecked at by the usual suspects.
It will eventually come loose.
When it does (no, no if) Devuan+all derivatives will need a fall back position.
[/OT]
That said, a basic Devuan installation (like a netinstall), would (by definition?) not have a DE or a WM for that matter.
So no radical change there.
Just a meta-package / script or whatever.
It would be downloaded separately and applied post-installation.
... a netinstall script, right?
Seems like it would be like that but for a Devuan netinstall.
ie: systemd less.
I really don't know how much of that script would have to be adjusted to work on a Devuan netinstall.
Thanks to all for your input.
Best,
A.
Hello:
... mistake to have posted that nonsense ...
Ain't necessarily so.
If XFCE is (like you seem to suggest) not going to the chopping block, all the more reason to find a sleek alternative for Devuan.
This because whatever sleekness XFCE may have once had is long (long) gone.
The alternative need not be incorpporated into the *.iso.
Ideally, some sort of #! Openbox meta-package to download and apply to a basic Devuan installation.
So I'd say that your cryptic comment can stay.
It has served a purpose while at the same time serendipity has proven its existence.
Once again.
Best,
A.
Hello:
... ballsy choice for Devuan ...
I think it fits Devuan just right.
In the true Linux spirit.
... could sure help with implementation ...
That would be great.
... would add a lot of complexity to the *.iso ...
You know better than I, but I was not referring to an out of the box thing, ie: incorporated in the *.iso.
What I had read about (if I undestood it correctly) was a script you could download and run on an basic Debian installation.
ie: one without a DE/WM, after the installation was finished and everything else was running as expected.
Found the post by HoaS here.
Have a look and tell us what you think.
Maybe a different thread?
Edit:
https://archive.org/details/sharpbang-b … 386.hybrid
https://archiveos.org/sharpbang/
Best,
A.
Hello:
As sometimes happens, we are veering away from the original topic. 8^°
... my vote goes to MATE.
The best (albeit not a DE) I ever came across was the one Philip Newborough set up in the original #! Waldorf.
Hands down: fast, light, nimble and absolute lack of useless bloat.
XFCE lost it, long ago.
Bloated, bugsy ...
I will not be taking it beyond the present version.
I recall seeing (at one time or another) a post (somewhere) making reference to a script than would put the #! OB WM on a basic Debian installation.
I vaguely remember that HoaS had something to do with it.
ie: the script or the reference, cannot recall.
Best,
A.
Hello:
... doesn't do squat ...
So I have discovered, thanks for the heads-up.
I had a start-up entry in xfce+Session and Startup+Application Autostart and unchecked it.
Ran through all my routines and they worked perfectly well, so I just uninstalled it.
Worst case, I'd have to re-install it.
... supposed to be securely storing the users passwords that you save when browsing ...
I would not be caught dead doing that. 8^°
... uninstalling the pkcs package ...
That I don't have.
The only gnome thing I have is the gnome-disk-utility which has given me no problems.
I have found it quite useful but it comes with a (built-in?) gnome-disk-utility notification plugin which I never set to startup.
You will find it in /usr/libxec/gsd-disk-utilty-notify.
That's that, so I'll mark this one solved.
Best,
A.
Hello:
I don't have ...
I deleted them all, no noticeable ill effects.
It would seem that they are a remnant / consquence of bad shutdowns, remaining cached because the system was unable to flush them.
See here.
But then, the next post has a bit that relates directly to gnome-keyring being the culprit:
gnome-keyring will create the control socket in ~/.cache/keyring-* when it cannot access the XDG_RUNTIME_DIR location. This happens every time on slackware, due to the pam stack configuration in the /etc/pam.d/system-auth file. Specifically the last line where "pam_gnome_keyring.so auto_start" is run (this step creates the control socket).
The problem is that here in system-auth, the gnome-keyring auto_start line is *always* called before pam_elogind.so, so it will never have the XDG_RUNTIME_DIR available and will always create a socket in ~/.cache instaed. This can then lead to stale files and whatnot as you see.
greenjeans says it is broken and this is probably (?) part of the damage.
I concurr with another poster's opinion in that thread ...
I'm allergic to residual and redundant cache and tmp files (IMHO they should be overwritten when new files are created or deleted after shutting down the program in question).
... but the solution posted does not apply to Devuan.
ie: there is no /etc/pam.d/system-auth file in my system
So maybe the solution is getting rid of gnome-keyring.
Q: how do I know if it actually being used?
Best,
A.
Hello:
... never seen anything in ~/.cache that couldn't be deleted.
That's what I think, but the fact that they are cached makes me doubt.
ie: why are they not cleared on reboot?
... zero keyring files in mine ...
... Bleachbit ...
... basically wipes everything out ...
Good to know.
... uninstalled the gnome-keyring ...
... badly broken ...
Why am I not surprised?
This is what I have installed in terms of 'keyrings':
$ apt list | grep installed | grep keyring
debian-archive-keyring/stable,stable,now 2023.3+deb12u2 all [installed]
devuan-keyring/stable,stable,now 2023.05.28 all [installed]
gnome-keyring/stable,now 42.1-1+b2 amd64 [installed]
python3-keyring/stable,stable,now 23.9.3-2 all [installed,automatic]
python3-keyrings.alt/stable,stable,now 4.2.0-1 all [installed,automatic]
$ Q: just how many keyrings do I need for my desktop?
Best,
A.
Hello:
This morning I came upon over 145 keyring-* sub-folders in my /home/user/.cache folder.
The contents of these folders fall into two categories: control and pkcs11.
What calls my attention is that they are quite dated:
2018 (1)
2019 (91)
2020 (12)
2021 (2)
2022 (1)
2023 (1)
2024 (29)
2025 (10)
As you can see, only 10 are from 2025.
I ssh into a NAS and the VM where my Pi-Hole / unbound set up runs and sometimes into my fibre router to check what evil the telco is up to.
Q1:
Why are they cached?
Q2:
Can these folders be directly deleted?
If not, how are they be cleared?
These are the backends I have in my system:
$ keyring --list-backends
keyring.backends.SecretService.Keyring (priority: 5)
keyring.backends.chainer.ChainerBackend (priority: 10)
keyrings.alt.file.PlaintextKeyring (priority: 0.5)
keyring.backends.fail.Keyring (priority: 0)
keyrings.alt.file.EncryptedKeyring (priority: 0.6)
$ Please advise.
Best,
A.
Hello:
... meant that the init script does not start ...
... enable it with update-rc.d.
Right ... 8^°
Sorry, my bad.
Yes, update-rc.d uses the INIT INFO fields and is mandatory when adding a script to /etc/init.d.
Best,
A.
Hello:
... not actually in Devuan repos ...
... not sure how to propose it.
... be enabled by you ...
No, not me. 8^D!
I'm just an interested observer.
That would be one of the admins (@golinux / @fsmithred / @Ralph.Ronnquist).
But I don't know what the process is / entails.
Best,
A.
Hello:
@Raulcla
@Kristof12
The site's search function is quite useful.
You may want to consider trying it out.
That said, have a look at these two threads:
https://dev1galaxy.org/viewtopic.php?id=2918
https://dev1galaxy.org/viewtopic.php?id=2449
TL;DR
Devuan is a systemd-less distribution.
snapd requires systemd -> because of this, snapd is a banned package.
Hence the lack of snapd or anything snap related in the Devuan repository.
Best,
A.
Hello:
... available because ...
... excalibur i386 live-isos and included xfe.
Good to know.
I have no hurry, the automount was needed for my U24 box but these days I can manage with a Ventoy *.iso, but it is a good addition to xfe.
Also have to carefully consider the convenience of upgrading the 1000HE to Daedalus / Excalibur.
Kernels suffer more and more bloat with each release
But the 1000HE's hardware is the same one as (quite obviously) nothing has changed since 2009.
Given the use it has, I'm not sure I see any advantage in upgrading.
... chance that the excal deb will install.
The one I'd want is 2.1 with the automount and all the bug fixes.
... probably have to get the upstream non-debianized source ...
I've written to the author asking what he has available.
I'll post back if/when I hear from him.
... package it or compile it ...
I thought as much. 8^°
Thanks for your input.
Best,
A.
Hello:
... ported the zramen script from Void Linux ...
... comes with a working init script for Daedulus.
Thanks for doing that for the team Dev1.
Best,
A.
Hello:
Still working on my Asus 1000HE. 8^°
My netbook runs on Devuan Chimaera and the lightest file manager ever I found (besides mc) was xfe 1.43.1-1 i386.
Worked great and never looked back.
This morning I got a notification from the author about a request I made (back in ascii days) for an automount feature which has been incorporated to lhe latest version (2.1).
**[feature-requests:#237] Automount devices in Xfe**
**Status:** open
**Group:** v1.0_(example)
**Labels:** automount
**Created:** Tue Dec 03, 2019 12:48 PM UTC
**Last Updated:** Sun Mar 14, 2021 05:28 PM UTC
**Owner:** nobodyXfe now has an (optional, Linux only) automounter. You can configure it in Xfe / Edit / Preferences / Settings.
The thing is that I don't see any i386 version in the Devuan repositories but I can find version 2.0.1-2 in the Debian repositories (Trixie) so I expect that the latest version ie: xfe 2.1 i386 will eventually (?) be available there also.
There are also i386 versions available for Buster, Bullseye and Bookworm, all of them ideal for undepowered i386 hardware such as the 1000HE.
I doubt xfe2.0.1-2 i386 would install without issues in my Devuan Chimaera netbook.
Or maybe not ...
Q: Is there a way to get that done?
Best,
A.
Hello:
... my https://github.com/eylles/zram-service script ...
Yes, I saw it.
But this is for an undepowered (Intel Atom N280/2Gb) ca. 2009 netbook for which I need a simple/easy solution.
The zramctl command can set up all the parameters I need in a jiffy in case the default ones are not suitable or I want to experiment.
Thanks for your input.
Best,
A.
Hello.
... troubleshoot this further?
No need.
In true (and time proven) Linux fashion I found a way out.
ie: by doing it in a different manner.
For those interested, the whole explanation is here.
TL;DR
For whatever reason, it seems the problem of getting the/a zram script to start in /etc/init.d has been doing the rounds for a while.
I could not find out why.
The solution is to start zram, setting the parameters and the zramswap file directly from rc.local.
And Bob's your uncle.
To test, I just dropped in the lines posted but (just to be neat) I'll write up a short script as a replacement for that.
Best,
A.
Hello:
Still working on my Asus 1000HE. 8^°
I have set up zram / zramswap with this script which I found referenced here.
Just in case, I added both the shebang (#!/bin/sh) and the usual PATH= variable as I saw it was missing.
I then named it zramswap, copied it to /etc/init.d, made it executable and did update-rc.d zramswap defaults.
The problem I have is that it does not start at boot and I can't figure out why.
But I can start it from a terminal:
$ sudo zramswap start
Setting up swapspace version 1, size = 1002.6 MiB (1051303936 bytes)
no label, UUID=05decff9-d90e-4db3-ae9d-a65484a3462c
$ $ sudo swapon -s
Filename Type Size Used Priority
/dev/sda5 partition 12595196 0 1
/dev/zram0 partition 1026664 0 20
~$ $ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda5 partition 12595196 0 1
/dev/zram0 partition 1026664 0 20
$ $ sudo zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 1002.6M 4K 74B 4K 2 [SWAP]
$ I can't get anything from running the script in a terminal either:
# /etc/init.d/zramswap start > /tmp/zramswap.log 2>&1
#
# cat /tmp/zramswap.log
# <- nothing to see here ...Just in case ...
#!/bin/sh
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides: zramswap
# Required-Start: $syslog $time $remote_fs
# Required-Stop: $syslog $time $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Linux zramswap setup
# Description: Debian init script for zramswap
### END INIT INFO
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/sbin/zramswap
PIDFILE=none
_is_active() {
$DAEMON status >/dev/null 2>&1
return $?
}
do_start_prepare() {
if _is_active; then
log_warning_msg "$NAME is already active"
exit 3
fi
}
do_start_cmd_override() {
$DAEMON start
}
do_stop_prepare() {
if ! _is_active; then
log_warning_msg "$NAME is not active"
exit 3
fi
}
do_stop_cmd_override() {
$DAEMON stop
}
do_status_override() {
$DAEMON status
}
do_restart_override() {
if _is_active; then
$DAEMON restart
else
$DAEMON start
fi
}How to troubleshoot this further?
Thanks in advance.
Best,
A.
Hello:
... @Altoid is quoting and replying to his own posts ...
Yes.
Instead of editing the previous post, I posted again.
Makes more sense when you are following the thread.
Granted, I neglected to add Update at the beginning of the post the quote to myself.
Sorry about that ...
But I digress ...
Running apt clean or apt autoclean requires root or sudo.
Depending on how your system is configured.
# apt clean
# # apt autoclean
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
# Likewise, to run apt-get clean or apt-get autoclean also requires root or sudo.
# apt-get clean
#
# apt-get autoclean
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
# With respect to apt-cache ...
You are quite right: clean and autoclean are not valid options.
What has happened is most probably a typo on behalf of one of our (most active) admins: fsmithred.
Strange ...
I have been a member of Dev1 for eight years now and it is the first time I see such a thing.
No big deal, just this week I have made more than a half dozen typos myself.
Happens.
So, no.
My guess is that you are not losing it, whatever it may be.
I keep my own it in a small box under the kitchen sink so it does not get lost. 8^°
Hope that clears up things for you.
Best,
A.
Hello:
I use apt autoclean and apt autoremove along with apt install -f all the time.
Yes.
apt autoclean will remove obsolete packages but to clear the /var/cache/apt/archives and /var/cache/apt/archives/partial directories you have to use apt clean.
Just checked in my netbook's Chimaera system and I came across a dozen or so packages from over three years ago.
Makes sense.
They were there because I never use apt clean, just apt autoclean and apt autoremove.
Best,
A.
Hello:
Which Trackball device do you use ...
I have been using a ERGO M575, I think also from Logitech.
It was the least expensive (wireless) one I could find locally.
It is quite evident that it is not made to last.
Not crazy about it, lint builds up inside the ball cavity, especially around the contact points.
But then I have seen that happen in every other one of these things I have used, I guess it is part of the deal.
One pet peeve I have is that the rubber pads that keep them from sliding on the desktop are (usually) absolute crap.
They are stuck on with some sort of rubber cement and eventually they will come off.
And to clean the thing thoroughly (under the buttons, around the wheel), you have to take it apart.
This means that (besides the necessary patience and care) the pads must come off to have access to the tiny screws.
Lose them (a pad and/or screw) and you are in a jam.
You may want to consider trying possible options out before purchasing one.
My only recommendation is to avoid any brand/model with rechargeable batteries.
Common AA's are available anytime / anywhere.
Best,
A.
Hello:
Maybe having lz4 in /etc/initramfs-tools/modules ...
Indeed ...
That would have done it.
Except that, for some reason, I decided to add an (obviously unneeded) underscore.
Hence it not working as expected.
What's lz_4 ?
Hmm ...
Direct consequence of not taking my 20:00 pill?
Or maybe taking it twice. 8^°
Now it works. 8^)
--- snip ---
[ 4.473334] zswap: loaded using pool lz4/z3fold
--- snip ---There's nothing like paying attention to what you are typing.
While you are typing it.
Thanks so much for you input.
Have a good week-end.
Best,
A.
... Bleachbit do the heavy lifting ...
My favourite was fslint but it's now long gone on account of python 2.7.x being deprecated.
Best,
A.
Hello:
... see my Edit: comment.
Yes, I saw it.
I use apt autoclean and apt autoremove along with apt install -f all the time.
But I have read that they do not take care of what has accumulated in /var/cache/apt/archives and /var/cache/apt/archives/partial.
Sorry, cannot find the link ... 8^°
Thanks for your input.
Best,
A.