• 17 Posts
  • 23 Comments
Joined 5 months ago
cake
Cake day: February 10th, 2024

help-circle
  • Edit replacing my original comment:

    Looks like that package has been superseded by org.gtk.Gtk3theme.Breeze. That’s what I’m using, and it is receiving updates.

    $ flatpak remote-info flathub org.gtk.Gtk3theme.Breeze-Dark
             ID: org.gtk.Gtk3theme.Breeze-Dark
            Ref: runtime/org.gtk.Gtk3theme.Breeze-Dark/x86_64/3.22
           Arch: x86_64
         Branch: 3.22
     Collection: org.flathub.Stable
       Download: 156.9 kB
      Installed: 386.6 kB
    
         Commit: 5a19b0c0808f82290d1f64c95d2406a860329817e0f269b4aaf0a1bbba92323a
         Parent: 390f820d32df2f22e3a3165eb4d65071dcb93a357ae7730f4ca548b5d016b966
    End-of-life: This theme has been replaced by org.gtk.Gtk3theme.Breeze, see README for workaround on using system color schemes. https://github.com/flathub/org.gtk.Gtk3theme.Breeze#workarounds
        Subject: Add EOL (fc4339ff)
           Date: 2022-02-22 00:21:51 +0000
    




















  • 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.


  • 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.


  • 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?







  • I’m glad to see revived interest in a full-featured music player.

    Others who find Elisa too simplistic might want to give Cantata a try. Unfortunately, its development has stopped, but it still works well in my experience. (It uses mpd for decoding and playback, so formats and encodings remain up to date, and that stuff stays hidden in the background rather than burdening the user with mpd configuration/management.)

    I used Clementine for a while when I was on a Gtk desktop, but privacy problems led me to abandon it. (It loaded Spotify’s proprietary code blobs and quietly pinged geolocation services without asking my permission.)

    Most Kirigami apps don’t both with this at all

    Was that part of the sentence an autocorrect error? I don’t know how to parse it.