You are not logged in.
In xfce4 thunar, it will either open a new tab or create a new folder as soon as i right click into white space sometimes, i usually have to hold the right button down to ensure it stays within the rightclick menu . . .
My muscle memory has adapted to this unwanted selection glitch. In fact I don't remember it happening in quite some time. Maybe it helps that I have set rather slow/lazy mouse reaction times.
Well . . . I have good news to report. I have been unable to create an iso with refractasnapshot for a very long time despite excluding ALL of my /home directory because the iso were always too big. So fsmithred and I decided to test your discovery. He instructed me to change line 1010 from this:
xorriso -as mkisofs -r -J -joliet-long -l ${isohybrid_opt} \To this:
xorriso -as mkisofs -r -J -joliet-long -l ${isohybrid_opt} -iso-level 3 \It took refracta-snapshot-gui a very long time to copy and squash the files since I had deleted the work directory but eventually it finished with a 4.9GB iso.
Then it was time to try it in qemu. I was delighted to see the boot process working as usual!!!
Now I need to redo the exclude list to include a basic home structure and perhaps delete a few things elsewhere starting with avahi.
I am overjoyed that I can now use refractasnapshot again. And this is also a milestone improvement for refracta! Thank you, thank you alphalpha!!!
Don't we have a sticky section where these things can go and live forever?
Reality check . . . nothing lasts forever. That being said, to date no posts have been pruned from this forum and would only be done manually with great care on my watch (which of course is also not forever for obvious reasons).
Welcome, miozin.
And of course read the Release Notes.
fsmithred . . . doesn't lightdm require a different backend than slim? I never could get that straightened out.
@thezeit . . . I sent you an email. You might have it blocked
ChuangTzu wrote:Or going default openRC.
https://wiki.debian.org/Debate/initsystem/openrc
https://wiki.gentoo.org/wiki/OpenRCI saw no mention of retiring OpenRC support on the Debian thread, I am also thinking this should be considered in regards to Devuan; default to OpenRC. I am running OpenRC on all my Devuan installs and havent encountered any problems. This is personal opinion, but I find OpenRC easier to understand over sysvinit, and prefer it. Please, dont want to start any flames nor arguments here.
Currently openrc relies on sysvinit helpers so still tied to it. Please refer to that thread on DNG. If those helpers are removed, openrc will be in trouble until there is a mature substitute to take over that function like runit. we're not there yet.
@thezeit . . . Already being discussed. Care to do more than suggest solutions? Maybe roll up your sleeves and get your hands dirty? We can always use more hands on deck.
There has been discussion of printers recently on the DNG mail list. I glossed over most of it because it was TMI but I suspect you might find an answer in there.
Panopticon wrote:Maybe something like a Lua script, ala conkyrc to conky.config ?
There's a Python-based converter from systemd to sysvinit here:
https://github.com/akhilvij/systemd-to- … -converter.
Yes. We already are aware of that. There will be a way forward.
Unfortunately linus has submitted to the CoCs.
He's between a rock and a hard place. CPS has been called and he's been deemed unfit to run a daycare. Having his baby snatched from him is unthinkable but a real possibility if he doesn't submit to this crap. He should fork the kernel and kiss the LF behind. Hey, I can dream . . .
It is not anywhere in Devuan/Debian: https://pkginfo.devuan.org/cgi-bin/d1pk … elease=any Maybe that's not the correct pkg name.
Also posting this news here to keep all Devuan users in the loop. Solutions are being discussed . . .
Many of us knew this day would come. The lock-in is nearly complete.
Holger Levsen Sat, 13 Oct 2018 04:15:19 -0700
On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
> > Has policy changed regarding support for multiple inits, or is it just that
> > no one is maintaining the shim and sysvinit-core?
>
> The latter. systemd-shim has been orphaned for over 2 years, and has
> RC bugs. sysvinit currently has two maintainers, but they've only
> ever made one upload (over a year ago).It seems that these facts are either largely ignored or unknown and I
wonder if some noise should be made so that interested people can pick
up the work now and not only complain later.
Source: https://www.mail-archive.com/debian-dev … 55832.html
As Christopher Barry said in his Aug 12 2014 Open letter to the Linux World:
OneLinux == zero-choice
Have you read the "Session management and policykit backends" section in the Release Notes? Looks like Mate uses slim + consolekit.
Thanks. A link should be fine.
I have had .xsession-errors files much larger than that because I forget to check. My home stuffed with ~250 GB so that file isn't a noticeable blip. It is possible to open those logs. Just change the encoding.
Please use code tags.
Is there a reason you posted the same text twice? I could edit it but would prefer that you correct your own post.
@HextorBRX . . . see how useful the DNG mailing list is?
auto.mirror was deprecated but then this happened a few weeks ago and now announced again after an oversight:
https://webmail.dyne.org/?_task=mail&_mbox=INBOX
Please consider joining the DNG mail list to keep current.
Btw golinux i remember that u used to tell me off that i chat with people on #devuan and i should go chat on #devuan-fork instead, haha. I didnt have idea that you're administrator ;D
Yup. And I carry a big stick! LOLOLOLOL! I often try to move chat unrelated to Devuan from #devuan to #debianfork. And I sometimes move topics here too. Think of it as housecleaning. Thanks for posting in the appropriate place on this forum.
@dxrobertson . . . Please read MX Linux' systemd policy:
MX Linux ships with systemd present but disabled by default. The MX Linux team strongly urges users to remain with this configuration which uses sysvinit instead.
I don't consider this approach systemd-free as all the "tentacles" needed to enable systemd are still present. It's no more systemd-free than a vanilla Debian with sysvinit. Yet the systemd-free label persists. Go figure.