You are not logged in.
Aaargh, good ol' .xsession-errors again...I have a love/hate relationship with that function.
I have after much work, made Vuu-do's file almost pristine perfect in Openbox/PcmanFM, yet if I switch to Mate, with all else being exactly the same, i'll get some glib-gio critical error nonsense fairly regularly. At one point it went ballistic but upstream fixed that pretty quick.
Something about DE's man...they all come with issues that it's hard for a user to fix locally.
OP, what kernel are we talking about?
Lol. Sounds like somebody fat-fingered that middle-click once too often and exploded into geek fury. ![]()
Not about "patents" as such
.
I'm aware of that and the other info posted afterward, for brevity's sake I didn't post it all because OP just wanted an answer to his question so I made a quick reply.
You're fine bro! The amd64 is not referrring to amd chips specifically, AMD was just the first one to patent 64 bit, thus the architecture itself is referred to as "amd64". You will be fine, Devuan runs great on Intel machines.
I'm really loving this simple app, it has multiple uses depending on how you compile it, I just now thought of using it as a recipe app, gonna compile a new binary and change name and DB folder to have a dedicated recipe version.
Lol, chatting with wife now, and she wants one for knitting/crocheting patterns. ![]()
I have no idea really what's going on, but when troubleshooting always rule out the simple stuff first. Do you have a keyboard shortcut of some kind for the display settings gui? If so, sticky keys can cause weird behavior.
Has anyone had better luck with Brave???
Yeah at least on Daedalus, running it right now, works fine after you do some initial work on settings. Ad-blocking is pretty good.
Main thing I like about it, is that it's not Firefox. Second thing I like about it is that it's not Firefox. No ridiculous scrollbar nonsense, that's another plus.
Nice! Thanks for all your hardwork, you and the entire Devuan team!
There were some small issues that I want to mention:
1. I changed http://gnlug.org/pub/devuan/merged to http://deb.devuan.org/merged. It was slow for me.
Hopefully those are mirrors and I didn't mess things up. Right?
Not a problem, gnlug is what I use but whatever works best.
I am curious about this. I did a dist-upgrade to Excaliber, as I have done ever since my initial install of ASCII, but I did put the Excaliber iso on a ventoy thumb drive just in case. Can you expand on why the installer doesn't work with Ventoy, or is that best suited for a separate topic?
Was just talking about this on another thread, Ventoy had issues with Daedalus, but it's working again in Excalibur according to rolfie.
Thats true for Daedalus. All older iso's work fine on Ventoy, also does Excalibur (again).
Cool, did not know that as I don't use Ventoy, just did some reading of the threads here about issues.
Spectacular use of new language here!
Respect!TC
No doubt, I had to look it up and it's definitely a thing, I mean I know what fractals are as I work with them a lot, but "fractally wrong" is it's own thing apparently!
Test Refracta Snaphsot as this is kind of a showstopper
Well i'm your huckleberry for sure when it comes to testing Snapshot, lol. It's no exaggeration for me to say i've used Refracta Snashot around 250-300 times in the last year, both on Daedalus and Excalibur, and never once experienced a failure. I have isos available online now made with it, again with both daedalus and excalibur.
FYI Devuan doesn't work properly with Ventoy, there's some threads about that on here.
Points well-taken, perhaps I did overreact a bit. In any case this query is now solved. So thanks to all who weighed in.
Check your other thread OP, this may be related to: https://bugs.debian.org/cgi-bin/bugrepo … ug=1123750
It's the same kernel that's giving you problems, just manifests differently maybe.
Arrgh, I think you may have the bug that's in that kernel though your behavior is different, this may be responsible for your other issues too.
There's another thread on here somewhere I think, I heard about the bug on IRC, some commit to that kernel version screwed up things.
Can you narrow down when this started with respect to package upgrades (if any)?
If you haven't updated recently and the problems just started out of the blue, then I suspect that's old hardware giving up the ghost slowly.
I have a 2005 lappy, old Athlon chip and 1 gb of ram that i've nursed along for quite a few years, but it started doing something similar and then just got worse until one day it simply would not power up.
But expecting defaults in a general purpose distro to be tailored for that is ridiculous.
Read the above that you wrote again, very slowly, and focus on the bolded part.
"general purpose" to me means it can work on anything, and I never said I expected things to be tailored to my hardware.
"defaults" ought to start with the lowest common denominator, it ought to work perfectly on older hardware, and thusly will work even better on newer machines. Users with better hardware are then free to bolster their system with various speed tweaks if needed.
Oh noes, 0.03% of precious RAM wasted on my 14 year old hardware.
omg well for sure move 0.03% of stuff into ram then, my gawd we've saved SO MUCH speed because lawd knows it will take my machine just forever to read that stuff. I do love saving me some tenths of microseconds.
You're just complaining now about me having the nerve to complain Steve, possibly you may want to ignore me because i'll likely complain again before it's all over with. ![]()
Right back atcha friends, thanks for a great year, i'm excited about what comes next in this new year!
Okay, just threw up a tar.xz of the prototype, there's no .desktop yet or packaging, the tar.xz just contains the source code, the compiled binary, and the compile command in case anyone wants to mess with it. It has no depends other than gtk, to compile yourself you just need libgtk3-dev in addition to the usual compiling stuff like GCC.
I can't find any bugs now, and behavior seems very good, but this is a prototype, so there may be some extraneous code and such, and there may be dragons still. Thanks for testing!
Sorry to be the voice of moderation here, lol, but pretty much every science fiction story ever written has all kinds of calamity in it by design, people wouldn't read it or go to the movies if it was just mundane everyday life described.
People who design AI say it will be the best thing ever, and then on the other end of the scale there are people who say it will be the worst thing ever.
And here I am in the middle as always, having lived through dozens of these disruptive technology moments and listened to all this before, still saying the same thing which is nearly always correct:
It can be a good thing, or a bad thing, just depends on how people use it. But it won't be the end of the world.
Try optimism people, glass half-full.
Lol I know older folks that have still never used a computer a day in their life because they think it's the devil.
I would rather spend the time to take what's useful OFF of gtk2 than to keep gtk2 running at all. That's where I am at this point.
Sadly, that's kind of where i'm at, it's why i've been trying to develop uber-simple apps with GTK3 that are reminiscent of the simplicity of GTK2.
I don't see the harm of leaving gtk2 and gtk2 apps in the repo though, there's lots of them that still work fine. Removing it all together and bullying devs into porting to gtk3 seems a little control-ish to be honest. Alsaplayer-gtk has been removed after debian badgered the dev to port to gtk3, he said screw that I just won't ship the package anymore and it will be CLI-ony now.
Steve, the milk of human kindness come to warm the place up again, happy New Year buddy! ![]()
which reduces SSD writes
I'll admit, hadn't thought of that angle, as I run spinning rust and not short-life-expectancy ssd's.
improves latency for applications that make frequent use of /tmp.
Horsefeathers. They're both solid-state, there won't be a noticeable difference. There won't even be much of a difference on a machine like mine with an HDD. If I wanted everything in ram i'd load a live-session.
On most systems /tmp is only a few MiB, and has negligible impact on available memory.
It's not the only thing living in ram these days, ram usage overall is more than double what it was a few short years ago, and there's lots of people running old hardware with low ram that need the extra. Not everybody has 32-64 gigs of ram, some folks are on a budget, i'm running 4 gb myself and i'd like to keep it clear.
So it's good to know now that i'll have a choice in the matter, which was the whole point of the post. ![]()
Some days I really wonder if this whole board isn't just a place to bitch about upstreams, other distros, and anyone who ever dared to change anything.
People have a right to do these things, if nobody ever complained every system in the world would suck.
And lastly, for myself, I don't just complain, I do something about it pretty regularly.
Srsly, hope you had a good Christmas and all the best to you and family in the New Year!
From this link: https://www.debian.org/releases/stable/ … in-a-tmpfs
5.1.6. The temporary-files directory /tmp is now stored in a tmpfs
From trixie, the default is for the /tmp/ directory to be stored in memory using a tmpfs(5) filesystem. This should make applications using temporary files faster, but if you put large files there, you may run out of memory.
So is this in Devuan too? Not running excalibur on anything right now so no way to check.
I 100% do not want that behavior on my machine.
The default is to allocate up to 50% of memory to /tmp (this is a maximum: memory is only used when files are actually created in /tmp).
50% of my ram by default... *edit to remove implied profanity because feels*
I swear the debian devs must have just gotten way too bored in 2024, and decided to do random nonsense to pass the time and create more work for everyone, this is almost as stupid and useless as usrmerge.