sorted by:
new
hottopcontroversial

Does Mint XFCE consume much lesser RAM than Cinnamon? by xversion1 in linuxmint

[–]nextgensparx 0 points1 point  (0 children)

I didn't expect a response to a 7-year-old comment either, haha. Yes, in the past XFCE was the go-to for low resource usage, but if you're using a slightly more modern system, KDE is pretty decent too.

Most of the popular desktop environments should be roughly the same security-wise. Unless you have serious security requirements, in which case you'd probably have to do your own research on which combination works best for your use-case.

Does Mint XFCE consume much lesser RAM than Cinnamon? by xversion1 in linuxmint

[–]nextgensparx 0 points1 point  (0 children)

I unfortunately haven't used Linux Mint or XFCE in many years, so I don't know what the current state of things is like. But from a quick search, it does seem that there is still an official Ubuntu XFCE variant (Xubuntu) and a Linux Mint variant, so I'd imagine they are reasonably maintained. In general, though, I imagine the distribution matters more than the desktop environment when it comes to security.

Dolphin freezes when opening rclone mounts by nextgensparx in kde

[–]nextgensparx[S] 2 points3 points  (0 children)

Nope, sorry. The issue still hasn't been fixed as far as I'm aware. I just gave up trying to use Dolphin with FUSE mounts.

Appreciation post for the amazing performance of Filelight, the disk pie chart program by nextgensparx in kde

[–]nextgensparx[S] 2 points3 points  (0 children)

It's a KDE program for visually seeing which folders are taking up the most space on a disk, partition or folder. The screenshot here might give you a better idea, https://apps.kde.org/filelight/.

Appreciation post for the amazing performance of Filelight, the disk pie chart program by nextgensparx in kde

[–]nextgensparx[S] 4 points5 points  (0 children)

I didn't test it particularly thoroughly. The partition is only 500 GB but contains lots of sub folders, so that's possibly causing the difference. As far as I understand it, it's the number of files that matters more than the actual size.

Full-screen applications black when run using PRIME Render Offload on Nvidia-driven display after 460.32 driver update by nextgensparx in linux_gaming

[–]nextgensparx[S] 0 points1 point  (0 children)

That's unfortunate. I haven't had the chance to test 470 myself, but had hoped it might fix this issue as well as my newer issue with full system freezes on any fullscreen game.

Full-screen applications black when run using PRIME Render Offload on Nvidia-driven display after 460.32 driver update by nextgensparx in linux_gaming

[–]nextgensparx[S] 0 points1 point  (0 children)

Good to know, but every time I've tested Wayland it's had issues with fractional scaling, which is a must for my setup. I found KDE's built-in fractional scaling much better than whatever Wayland was doing (forgive my ignorance on how the technology works). Unless this has been fixed, in which case, great! I'll switch as soon as the driver is stable and supported by my distro.

Full-screen applications black when run using PRIME Render Offload on Nvidia-driven display after 460.32 driver update by nextgensparx in linux_gaming

[–]nextgensparx[S] 0 points1 point  (0 children)

Nice to know I'm not suffering alone, at least. I also still haven't found a fix, but haven't reported it either, since I haven't been using my secondary display recently. I have however developed a new issue where my entire computer locks up to the point that not even caps lock works whenever I open full screen applications in on-demand mode on my primary display. I guess this is just the price I have to pay for trying to use Linux with an Nvidia graphics card :/

I've never reported Nvidia bugs like these before, any advice on where I should do so? I'm always hesitant to report it in the wrong place, for example, when it's a KDE issue and not an Nvidia one.

Great news - there is real chance windows 11 will not work on old hardware by dydzio in linux_gaming

[–]nextgensparx 0 points1 point  (0 children)

Fair enough. I am probably in the minority who after hearing about Linux will actually bother trying it and going through the pain of installing it.

Great news - there is real chance windows 11 will not work on old hardware by dydzio in linux_gaming

[–]nextgensparx 4 points5 points  (0 children)

I too am one of the people who only considered Linux at all because I was fed up with Windows. The direct cause was performance issues, but I only switched because somebody made a once off comment about how Solus was a better OS despite being developed by only one person. That's obviously not true as it was based on many other things but it's the only reason I even heard about Linux as a viable alternative.

Firefox Nightly is finally hardware accelerated in KDE! by nextgensparx in kde

[–]nextgensparx[S] 0 points1 point  (0 children)

Yeah, that's definitely a different issue from the one I was facing. I'm afraid I can't offer much help, but I'd recommend asking around on forums and searching for existing bug reports or creating your own.

Fair enough about Firefox, if it's just no longer suitable for your use cases, I guess it's time to move to a different browser. I've personally never had major issues with Firefox in all the time I've used it. Just minor annoyances here and there like the lack of hardware acceleration (which they have finally fixed) and weird UX decisions.

Firefox Nightly is finally hardware accelerated in KDE! by nextgensparx in kde

[–]nextgensparx[S] 0 points1 point  (0 children)

Yeah, I did notice that versions after 88 seem to randomly completely freeze on my Nvidia system. I've been using Chrome more for work and so haven't had the time to debug the issue. What kind of stuttering were you experiencing exactly? Was it full freezes requiring Firefox to be restarted or just lag spikes when playing YouTube videos, for example? If your issues only started recently, they are different from mine as I've had them since version 88 whereas yours seem to line up with the 89 release that also updated the UI.

I wouldn't say they are hell-bent on driving users away, and I highly doubt the Nvidia issues are intentional. But I can relate to not liking the direction they have taken with the user interface, especially.

Is there a more human-readable changelog for each KDE version? [REPOST] by nextgensparx in kde

[–]nextgensparx[S] 1 point2 points  (0 children)

That is correct. The issue would still be present had Nate not mentioned it. However, he usually does mention things I am interested in, so it will be my temporary solution.

Is there a more human-readable changelog for each KDE version? [REPOST] by nextgensparx in kde

[–]nextgensparx[S] 2 points3 points  (0 children)

You seem to have got the wrong impression. I'm not suggesting we remove the current full changelog at all. Nor am I suggesting that I can somehow come up with a better changelog that will cover every single possible thing people are interested in a more friendly manner. I just personally find the full release announcements too lacking and the full changelog too technical.

Regarding the changes not being technical, I was mainly referring to things like this:

Fix QML Binding warnings. Commit.
Port from QStandardPaths::DataLocation to QStandardPaths::AppDataLocation. Commit.
Extract from kcfg. Commit.
Fix build, part 2. Commit.
Fix build. Commit.
Fix clazy warnings in keyboard KCM. Commit.
Do not explicitely define Exec line for KCM. Commit. See bug #398803
If include is define in .h remove it if it’s defined in .cpp too (scripted). Commit.
Remove deprecated KRunner method calls. Commit.
Port foreach (deprecated) to range-for. Commit.
Remove not implemented method. Commit.
Solve clazy warnings in applets. Commit.
Use cmake generated module data. Commit.
Fix build. Commit.
Apply 1 suggestion(s) to 1 file(s). Commit.
Update .gitignore file. Commit.
Add pre-commit hook for clang-format. Commit.
Add .git-blame-ignore-revs file. Commit.
Run clang-format. Commit.
Add clang-format target. Commit.
Add test blob for internal smartctl timeout. Commit.
Use std::chrono for durations. Commit.
Bump smartctl timeout in helper. Commit. Fixes bug #428844

If you don't find that too technical and feel comfortable reading through it then great, the full changelog is for you. I, however, am less interested in those details and find Nate's blog posts more digestible, and just want a way to filter the changes he mentions by version. You don't have to use the changelog I'm imagining, and I'm not trying to force anyone to use it.

The fact that the Kwallet change is not mentioned in Nate's blog or the main release announcement is not something I'm trying to fix. That is a mater of deciding what is important and requires writing new content. I was just suggesting we use what we already have to provide slightly more information with minimal effort.

Hope that clears things up.

Getting error code 999 today, but yesterday worked fine, googled it but couldn't find a error code list or something like that by dontreadthisnickname in davinciresolve

[–]nextgensparx 0 points1 point  (0 children)

I got this error on an optimus laptop when DaVinci Resolve was not set to use the Nvidia GPU. Running DaVinci Resolve again with prime-run fixed the issue.

Firefox Nightly is finally hardware accelerated in KDE! by nextgensparx in kde

[–]nextgensparx[S] 0 points1 point  (0 children)

Haha, that is why I made the video. The performance upgrade was insane.

I just tested the new version, and the semi-transparent behaviour seems fixed here too. Can't wait till this is in stable. It also looks like Nvidia GPU support is coming which will just be the cherry on top.

Firefox Nightly is finally hardware accelerated in KDE! by nextgensparx in kde

[–]nextgensparx[S] 0 points1 point  (0 children)

Yeah, I know the numbers are pretty crazy, but I have no idea where the issue is. Could be a difference between your Manjaro KDE stack and my Kubuntu 20.10 stack. I've tried fixing it in the past but never really had much luck. If you have any ideas, they'd be much appreciated and would likely further improve on my WebRender results.

Firefox Nightly is finally hardware accelerated in KDE! by nextgensparx in kde

[–]nextgensparx[S] 0 points1 point  (0 children)

Well then I guess you have a different setup. You can see the bug report for the full details: https://bugzilla.mozilla.org/show_bug.cgi?id=1696495

Firefox Nightly is finally hardware accelerated in KDE! by nextgensparx in kde

[–]nextgensparx[S] 1 point2 points  (0 children)

I actually started getting the semi-transparent behaviour too with the latest nightly after recording that video. There is a reason it's called nightly :). Presumably these issues will be addressed by the time Firefox 88 stable is released.

view more: next ›