No, that does not look right. Some of the versions mention on needed packages could be satisfied by jessie versions, some by ascii versions. I don't know what's going on with your system, but I will point out that as time goes on, ascii/stretch and ceres/sid will grow farther apart. You're really mixing stable with unstable, not testing and stable.

If task-mate-desktop is installed, it will probably keep you from losing all the stuff that comes with the task metapackage. Use the -s/--simulate option with apt-get to see ahead of time what it wants to remove. Note that apt-get will only mark packages for autoremoval, but it won't remove them. If you install any of those packages, they will be marked as manually installed, and they will be removed from the autoremove list. On the other hand,  aptitude will autoremove them when it removes the task package.

1. Install wicd-curses or wicd-cli or connman or setnet. (setnet is in the experimental repo)
2.

dpkg-reconfigure locales
dpkg-reconfigure keyboard-configuration

Install task-french. (and maybe task-french-desktop - check the dependencies)
3.

dpkg-reconfigure tzdata

Pinning systemd-sysv to -1 is sufficient to prevent installation of systemd. In fact, you don't even need that. I just tried installing systemd after removing /etc/apt/preferences.d/avoid-systemd and it's not possible.

root@ascii:/home/user# aptitude -s install systemd
No candidate version found for systemd   
Unable to apply some actions, aborting
root@ascii:/home/user# aptitude -s install systemd-sysv
No candidate version found for systemd-sysv
Unable to apply some actions, aborting

Any problems with ascii that we don't know about will not get fixed. Any problems caused by misconfiguration on your end won't get fixed until you seek help.

BTW, suspend works fine here. What destkop are you using?

Keep a terminal open with top running and look at it when the thrashing starts. Or click on the cpu activity monitor in the panel - it will open a terminal with top.

I found this. It's from 2014, so it may no longer be accurate. Also, please run the grep command I posted above to see if you get the same output that I got.

https://devtalk.nvidia.com/default/topi … 0/#4385920

I haven't heard much discussion of perl among the devuan devs. Maybe it just hasn't come up, or maybe we don't have any avid perl programmers. I think a lot of the package management stuff in debian (and consequently in devuan) is written in perl.

You can do a ./configure and make on a source package. Then run it from there. Don't do a 'make install' or you may screw up the system and confuse apt. Figure out what you need to do to get it to work. If you have to install other libraries, you should install them from the repo. After that, you can figure out how to get it into a debian package.  The basic steps for that are pretty simple. The devil is in the details. And looking at the current debian source to see how it was done should be helpful.

What kernel are you using? The message is clear. Either use a rt kernel or use nvidia driver, but you can't use both together. Which one is more important?

Edit: How are you installing the nvidia driver? Package from repo or binary from nvidia?

Sorry, I was busy doing other things. No, I'm not offended easily, as golinux mentioned, and certainly not about which editor to use. .I knew you were kidding. However, if I ever announce that I'm going to run notepad in wine, you are welcome to come down on me hard.

If you can make a package that works, you could put it up anywhere and tell people about it. If you want to try to get it into the devuan repo, you should set it up on git.devuan.org and follow the d1h directions in the Documentation section of this forum. Other than that, you seem to know what to do. Mess with the package, test it, and then I'm not sure why you would revert your system if you just created a solution. For versioning, you should check the debian documentation on that. You could use the same version as the source you're using and add a +something like we do for the devuan packages. But really, check the docs. It can be a bit confusing. (is for me, anyway).

Mint/ubuntu seem to be slow at everything. Not just booting. Trying to run them in a VM can give me an anxiety attack from waiting for something to respond.

Yeah, that makes sense. You tried to install grub-pc in a uefi system. You only need to install the grub packages if the wrong grub is installed in the live system. In this case, grub-efi is installed, so you should boot in efi mode and let the installer handle to bootloader. You might not be able to use legacy bios with gpt partitions. And that uefi readme in the user's home is probably wrong and needs to be updated.

It might be better to use the cli installer, because that's a newer version, and I know it works well in a uefi install. Run 'refractainstaller' in a root terminal, or even better, (if you can stand to look at additional and distracting output on the screen) 'refractainstaller -d' to get a more verbose error log.  One drawback is that you'll have to type in /dev/nvme-whatever to tell it which partition to install.

No emacs here. Just vi, which I do not like. I can tolerate vim, but plain old vi always screws me up. I inevitably hit an arrow key to move the cursor, and it spits out inappropriate characters. I would put vim on my isos, except for the fact that it takes up too much space, and I try to keep the isos down to CD size. But I'm perfectly happy with nano. If I forget how to use it, the instructions are right there in front of my face.

When you tried to boot after installing, did you get anything? A grub boot menu or even a grub prompt? If so, it should be possible to boot with the right commands.

Did you look at the efi partition to see if anything got copied there?
There should be /boot/efi/EFI/<devuan or refracta>/grubx64.efi