KDE

SomeoneSomewhere , in KDE Neon using tmpfs for /tmp seems like an horrible idea?

With software that misuses /tmp, I'm more worried about burning out my SSD endurance than running out of RAM.

Strit , in KDE Neon using tmpfs for /tmp seems like an horrible idea?
@Strit@lemmy.linuxuserspace.show avatar

2 good reasons to have your /tmp on tmpfs filesystems.

  1. It's faster. RAM speeds are faster than your drive speeds, even SSDs.
  2. You are certain that all the files are removed on reboot, because RAM always gets cleared when it looses power.

1 bad reason for having your /tmp be tmpfs.

  1. It can quickly fill out your RAM if your application (or you manually) drop huge files in /tmp and don't move them out afterwards.

In my mind, the Pros outweigh the Cons.

CameronDev , in KDE Neon using tmpfs for /tmp seems like an horrible idea?

I think, and i'm open to alternative theories, is that using RAM instead of disk is safer when the tmp directory fills up.

If you have /tmp being a regular directory on your root drive, if you fill your disk witg tmp files, other processes wont be able to save files to disk, resulting in lost data.

If you have it in a ram disk, when the tmpfs fills up too much, the oom killer can get more space (unsure if oomkiller can wipe tmpfs, but that probably would be ideal?).

Neither are good, and both can result in data loss, but tmpfs may be safer?

recursive_recursion ,

wouldn't that open up additional vulnerabilities?

CameronDev ,

Are you thinking rowhammer? My understanding is limited, but doesnt rowhammer require being able to write to memory at a consistent address, co-located with the data being attacked? Im not sure thats doable with tmpfs, but probably worth an investigation by someone more knowledgable than me :)

mox , (edited ) in KDE Neon using tmpfs for /tmp seems like an horrible idea?

Why would you drop a 10GB file in /tmp and leave it there?

Every decent app I've used that processes large files also moves them to a final location when finished, in which case it makes sense not to use /tmp for those, because doing so would turn that final move operation into a copy (unless you happen to have /tmp on the same filesystem as the target location). That's why such applications usually let you configure the directory they use for their large temp files, or else create temp files in the target dir to begin with.

For what it's worth, I changed my /tmp to a tmpfs years ago, even on a 16GB system, for performance and to minimize SSD wear. I think it was only ever restrictive once or twice, and nothing terrible happened; I just had to clear some space or choose a different dir for whatever I was doing.

It's worth reviewing the tmpfs docs to make sure you understand how that memory is actually managed. It's not like a simple RAM disk.

lumirell OP ,
@lumirell@lemmy.kde.social avatar

Why would it matter the reason of dropping a file of X size? The point is that not all applications are "decent" and some will undoubtedly use /tmp because "it might be the most logical thing" for any developer that's not really up to date.

I don't see how reviewing the tmpfs helps in this scenario if at all... we are talking about end-users your common joe/dane running your day to day applications, whatever they may be. I don't and will never expect developers to adhere to anything and just put out whatever.

mox ,

Why would it matter the reason of dropping a file of X size? The point is that not all applications are “decent” and some will undoubtedly use /tmp because “it might be the most logical thing” for any developer that’s not really up to date.

It matters because it's the difference between a real-world situation, and a fabricated scenario that you expect to be problematic but doesn't generally happen.

All filesystems have limits, and /tmp in particular has traditionally been sized much smaller than the root or home filesystems, regardless of what backing store is used. This has been true for as long as unix has existed, because making it large by default was (and is) usually a waste of disk space. Making it a tmpfs doesn't change much.

The point is that not all applications are “decent” and some will undoubtedly use /tmp because “it might be the most logical thing” for any developer that’s not really up to date.

In my experience, the developers of such applications discover their mistake pretty quickly after their apps start seeing wide use, when their users complain about /tmp filling up and causing failures. The devs then fix their code. That's why we don't see it often in practice.

I don’t see how reviewing the tmpfs helps in this scenario if at all…

I mentioned it in case it helps you to understand that the memory is used more efficiently than you might think. Perhaps that could relieve some of your concern about using it on a 16GB system. Perhaps not. Just trying to help.

we are talking about end-users your common joe/dane running your day to day applications, whatever they may be.

We are? I don't see them echoing your concerns. Perhaps that's because this is seldom a problem.

lumirell OP ,
@lumirell@lemmy.kde.social avatar

In my experience, the developers of such applications discover their mistake pretty quickly after their apps start seeing wide use, when their users complain about /tmp filling up and causing failures. The devs then fix their code. That’s why we don’t see it often in practice.

I humbly disagree. We don't live in that utopia.

I don't see them echoing your concerns.

I guess for an scenario to be real everyone has to know exactly what's happening? They will know what caused it and they will all know how to properly report it even though I don't even expect a lot of people to know their system especially your average joe/dane nor do I expect them to even troubleshoot the issue if something were to happen. It doesn't really invalidate the scenario at all.

A fabricated scenario is itself pretty redundant. :)

ulterno ,
@ulterno@lemmy.kde.social avatar

Nice.
I'm going to go set up tmpfs rn

CameronDev , in KDE Neon using tmpfs for /tmp seems like an horrible idea?

Arch uses tmpfs for /tmp by default as well. At least on my.install from 2-3 years ago

lumirell OP ,
@lumirell@lemmy.kde.social avatar

I... don't think I have ever seen it do that automatically unless I missed some steps in the installation guide...? most of the time I just created the partitions I needed. I did a quick CTRL + F on tmpfs or tmp but not seeing anything...

Anyhow, I don't see on my desktop which still has Arch Linux installed which I want to move to KDE Neon but extremely lazy when you have an immense backup to do...

Max_P ,
@Max_P@lemmy.max-p.me avatar

It's default since systemd afaik. I think systemd-tmpfiles manages this. It's never been a problem for me, it pretty much remains fairly empty most of the time. Most things like sockets are in /run which is also tmpfs.

Strit ,
@Strit@lemmy.linuxuserspace.show avatar

It has been default in Arch for a long time.

What is the output of your df -h | grep tmpfs command?
It should list a couple of devices using tmpfs, where /tmp is one of them.

boredsquirrel , in Cannot use system tray widget Plasma 6

How did you install Plasma? Did you install the plasma-meta package? If not, please do so.

Also, are you using Wayland or XOrg?

foremanguy92_ OP ,

I've installed the plasma package, but what's the difference?
And I'm using Wayland but prefer to not change it

boredsquirrel ,

Just some things. Wayland is officially supported, the plasma-meta package is basically needed.

baduhai , in Pretty impressive changelog for Plasma 6.0.4 (see the kwin entry)
@baduhai@sopuli.xyz avatar

It's a big one overall, nice.

tubbadu , in Pretty impressive changelog for Plasma 6.0.4 (see the kwin entry)

Nice

Metz , in KDE Gear 24.02.2

5 days old news?

palitu , in KDE Gear 24.02.2

Not really sure that this is?

dev_null ,

KDE Gear is the overall name for the suite of the "core" KDE programs, like the file manager, console, image viewer, etc.

palitu ,

Ah, thanks

mox , in Improvements to QTextDocument

it wasn’t hard to implement huge part of the markdown specification.

I wonder why you implemented part of markdown, rather than using QTextDocument's existing markdown support. Is something that you need missing?

I already have some patches up for review in Qt.

Will you submit one for Qt's markdown functionality as well?

daniel , in Kate on all Platforms - 2024
@daniel@vivaldi.net avatar

@cullmann I’ve tried using Kate across Linux, MacOS, and Windows. Unfortunately, the Windows port slows down if you keep using it without restarting it at least once an hours. I still use it on Linux but miss it on other platforms. It’s not enough that something is available on all platforms. It has to work well on all platforms too.

rriemann ,
@rriemann@chaos.social avatar

@daniel @cullmann If you cannot create yourself a bug report, could you please share some Infos here?

Which windows do you have? Can you see if Kate's RAM use increases over time? Does it depend on interacting with Kate or also happens when the app is open in the background only?

cullmann OP ,

It is not just available, both for Windows and macOS we try to get it to a good state and fix bugs. If that slowdown is reproducible, that should be fixed. But to do that, we would need more info, best would be to get some profile data for it.

sentient_loom , in Kate on all Platforms - 2024
@sentient_loom@sh.itjust.works avatar

Did AI write this?

dave ,
@dave@feddit.uk avatar

What makes you think that?

Bro666 Mod , in KDEnlive community?
@Bro666@lemmy.kde.social avatar

We asked the project maintainers, but they lack the resources and time to moderate a community like that at the moment.

boredsquirrel OP ,

Just fyi, I would be down to help moderate.

5PACEBAR , in KDEnlive community?

I discovered kdenlive a few months ago and it's amazing! I can't believe I didn't even know it existed. How come it's not as popular as paid options? It even runs on Windows

MentalEdge ,
@MentalEdge@sopuli.xyz avatar

It's not quite as feature rich as something like davinci resolve, which is straight up movie industry level software, yet it's free to use.

And resolve actually runs on Linux, too.

KDEnlive has also had some bugs over years. I personally started editing with it first, but ditched it for resolve due to a bug that would cause audio and video to gradually go out of sync over time, but only when actually rendering, and there was literally no way to work around It. I had no way to turn my completed edit into an actual usable video file...

I am back to using it, and it has improved a ton. It's extremely capable and has all the features most editing projects would ever need.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • [email protected]
  • random
  • All magazines