You are not logged in.
Sounds like another W for AppImages. You can certainly use your package manager or compile from source, but they are nice to have for offline systems that haven't been updated in years... Or dropping them onto USB flash drives so that if you use a shared public computer with Ubuntu or Fedora, you can still use your favorite software without wondering if the distro has it available. That's the beauty of choice.
A Debian-based system could still benefit from its locally stored repositories contained in the point release ISOs, but you can also use the DEB files (as long as the dependencies resolve) to install software without the need for going online. Slackware is the only non-Debian-based distro where you can still do offline installs, as long as you have the TGZ or TXZ files. AppImages are perfect for a lot of the other distros that aren't that good with installing packages locally, such as the rolling release types.
There are now efforts to improve the filepicker with things like thumbnailing without a file manager pointed to the directory already, tooltips, image previews, and basic UI context menu goodness.
As well on SteveM's git repository, the dependency conflict with gir1.2-gtk-2.0 to also keep stuff like Dia around has been fixed, and can be installed alongside gir1.2-dtk.
Get the Daedalus DEBs below:
Get the Excalibur DEBs below:
No idea about a DM that doesn't suck eggs and swallow yolks, and couldn't care less about Wayland "usability". I just do everything from TTY, using this very antiquated command:
startxThanks to SteveM, there are now unofficial packages for Daedalus and Excalibur users in this repository. Keep in mind that the naming decision is still in progress (i.e. we are not calling it the "Devuan ToolKit"), where you can vote in a poll for which one you like the most. It could still work out with DTK (if it comes down to that), with the D standing for something else other than Devuan out of careful consideration.
Along with Orphaner, I think it got deprecated by Debian indefinitely, as nothing exists past Bookworm sans Sid for RISC-V. You could try to install it from Daedalus.
I just use Debfoster now.
Figured I'd bump this, what with lots of media outlets reporting on this new fork. Most of the discussions are taking place at the Devuan Users Forum (an unofficial community for Devuan and other non-Systemd GNU/Linux and *BSD users) here.
Phoronix and even DistroWatch.com have already reported on this. Bryan Lunduke has also posted his video on this.
In the Devuan world is there anything that needs to be done to add firmware or otherwise make sure that wireless cards are detected? I have not had that problem lately with this computer I am working with with debian or artix or arch installations.
Try enabling non-free-firmware if you haven't yet (shown example line below):
deb http://deb.devuan.org/merged/ excalibur main contrib non-free non-free-firmwareUpdate your repositorites, and then install the particular firmware package(s) you need. Things like firmware-iwlwifi (Intel), firmware-brcm80211 (Broadcom/Cypress 802.11), firmware-realtek (Realtek), and so on. Follow the same steps that worked for you in Debian, as they should be the same in Devuan. This respin appears to be using NetworkManager, so these firmware packages should work just fine if the hardware matches. It just depends on what your system's wireless card is for it to work. For example, I recently bought 802.11 USB wireless card adapters for my laptops that struggle to connect without one (the aforementioned firmware-brcm80211 didn't support it), and had to rely on building a driver from this repository, since none of the firmware packages I installed were working.
I would very much like access to the MX Tools, especially including snapshot capability.
Have a look at this thread posted at the Debian forums.
Do note that this guide was originally posted in early 2020, so you'll have to change "buster" on the repository sources to "trixie" if using stable (which Excalibur is based on), "forky" if using testing, and so on. It's also not recommended to add third-party repositories to Devuan-based systems in general, in case of build conflicts with any of the distro's banned packages list.
But, give it a shot, and report back if any issues occur.
Why not just stick with IRC, XMPP, Mumble, Jitsi Meet, and a ton of other decentralized, privacy-respecting (as much as possible) FLOSS communication protocols?
Couldn't you just install or overwrite the official keyring DEB file?
wget http://deb.devuan.org/merged/pool/DEVUAN/main/d/devuan-keyring/devuan-keyring_2025.08.09_all.deb
sudo dpkg -i devuan-keyring_2025.08.09_all.debI haven't tried, since I don't want to go through all the fuckery introduced in Trixie. You also have to install UsrMerge before you even change your repositories over to Excalibur.
You can definitely remove or disable Elogind itself. You might have a harder time using a computer without the libraries most "conventional" packages are built against. ConsoleKit2 and Seatd can both help out more, plus the dummy Logind package (dummy-logind) that Devuan has made available since Daedalus. Since I need incremental RSYNC backups from Timeshift and Back in Time, Polkitd must be kept. Still, it's nice to have KDE and Network Manager functioning without any issues without an existing Elogind process (again, only the libraries are kept to avoid breaking the entire system).
Eudev is still a problem. I also personally removed Udisks2 and now use Udevil for automatic USB mounting as a non-root user (you can optionally use SpaceFM as an extra safety cushion).
As of Trixie, Debian has made it harder to remove or replace ALL parts of Systemd, never mind D-Bus (which is completely impossible to rip out and still have a functional computer). Devuan simply follows Debian's steps and applies its own blacklists regarding packages that have a hard dependency on Systemd. Elogind is used in place.
The only other Debian-based distro that has gone the great lengths to remove or lessen the impacts of Systemd or Elogind would be antiX.
As long as I can just click a button and it just works!
Mmm... Not quite.
chmod a+x /path/to/file.appimageThey will work then.
I've also been a vocal proponent of AppImages. If I can't use a working DEB file or compile it from source successfully, AppImages are nice to have for both portability and security (i.e. not having it interfere at all with your system data). Zero complaints.
Greenjeans already clarified he didn't hardcode any of that "inaccessibility" crap, and he did say he'll look into it, simply because he wants to help. It mainly comes down to which theme you use, as Rations mentioned. Wanting to cater to the visually impaired is nice and all, but it's not "mandatory", and hardly at all the end of the world because the current theme in use made it harder for you to tell things apart. That MATE screenshot was way more evident of visual issues.
The "historical relationship" is a moot point when you're just nitpicking over a theme's color and contrast defaults. That's why you can change it. Not a big deal.
Are you volunteering to do the theming for the software? No? It's his software, let him do whatever he wants.
There is no one-size-fits-all theme, ever. People are still gonna complain. ![]()
Have you tried dpkg-reconfigure tzdata?
@Daemonratte:
Consider using Devuan's official Git repository. That way, you ensure Micro$lop doesn't remove you for whatever reason, and your hard work isn't lost.
This is a good idea. Devuan's Runit and OpenRC (the latter I've never used, but have been informed on) implementations aren't as complete as other distros have theirs. I'd say even Slackware has a more pure SysVinit implementation.
Retroactive support for Chimaera and Daedalus is also a good idea, since there are many of us who have yet to switch to Excalibur and would appreciate more optimal service management in exchange.
No, mine also are grayed out for both shut down and reboot. That's why I use my custom logout script in place.
Assuming you also installed libseat1, have you tried to add your user to the video group? Something like seatd -g video as a superuser to fix that. I recall doing that to make Seatd work properly with X11. I have little to no issues with it. According to ps_mem.py, both ck-launch-session and seatd are in the running processes with a graphical session.
Are you running startxfce4 --with-ck-launch directly or from its contents in your ~/.xinitrc file? I use Xfce, and for the latter, that always works for me. Does it sound like an issue with Seatd permissions? There's also seatd-launch you could prepend to startx or startxfce4 --with-ck-launch. Also, for ConsoleKit2, I have the packages libck-connector0, libconsolekit1, and libpolkit-gobject-consolekit-1-0 installed alongside of it. I do not have libpam-ck-connector installed.
That's why I just use SpaceFM instead. Thunar is built to work with Udisks2, which works "best" with Elogind and whatnot.
If you add --with-ck-launch, ConsoleKit2 will be provisioning your X11 session.
I have no problems shutting down or rebooting with these YAD scripts:
For ~/bin/xfce4-logout:
#!/bin/bash
yad --window-icon=system-log-out --image="system-log-out" \
--title "Log Out" \
--text "What would you like to do?" \
--button="_Lock:0" \
--button="Log _Out:1" \
--button="S_uspend:2" \
--button="_Reboot:3" \
--button="_Shut Down:4" \
ret=$?
[[ $ret -eq 4 ]] && gksu poweroff
[[ $ret -eq 3 ]] && gksu reboot
[[ $ret -eq 2 ]] && xflock4 && gksu pm-suspend
[[ $ret -eq 1 ]] && killall Xorg
[[ $ret -eq 0 ]] && xflock4For the fake /usr/local/bin/gksu:
#!/bin/sh
set -e
if [ $(id -un) = root ] ; then
exec "$@"
fi
if [ "$SUDO_ASKPASS" = "$0" ] ; then
exec yad --entry --title="PASSWORD" --entry-label="$*" --hide-text
fi
exec env SUDO_ASKPASS="$0" sudo -A "$@"As far as drive mounting goes, no issues with Udevil's Devmon running in the background. I removed Udisks2 entirely.