[–] 3 points 5 months ago (1 child)

Swap is rarely hit, especially if set up with zram.

This is not a good thing btw. Any unused anonymous page takes up space that could instead be used for file-backed pages that make your system faster.

Multiple swap tiers beyond zram/zswap

Swap is not tiered storage!

Priorities control order of preference, not tiers. If you run out of space on a higher priority, it will not move that swap's data to a lower priority swap. It will keep all of it exactly where it is and new data will hit the lower prio swap instead, no matter how hot it is.

Intel Optane

Cool tech but it's dead and was quite niche even when it was alive.

zram write-back device

Not a thing you actually want to use for swap. It's not an automatic writeback that is integrated into the Linux MM in any way. (Probably has some use-case for non-swap zram purposes though.)

Large HDD swap partition used as a third tier swap disk

This makes no sense at all unless you are extremely space-constrained on the NVMe and absolutely must not OOM – even if progress stalls to an absolute crawl.

swapped pages can be moved around by the user (or a tool), by turning swap devices off and on.

This is neither feasible nor desirable. You don't have enough granularity to do anything useful by doing so.
Even if you had, it'd work against the MM because it resurrects pages as "hot" that have been cold for a long time.
In any situation where swap is important, making the kernel think cold pages are hot is the very last thing you want.


I too wish it were but tiered/transcedental memory is not a thing in Linux and these hacks do not change that fact; they merely look similar if you don't look close enough.

I cannot think of a single use-case where this would be preferable to a decently sized physical swap with zswap XOR just zram swap (if physical swap is infeasible).

  • source
  • parent
  • context
  • [–] 2 points 5 months ago (1 child)

    This testing compares apples to oranges. Differently sized swap and quite obviously different workloads. Given how very much compress ratios depend on the specific data that is compressed, this experimental setup cannot produce valid results.

    This is exacerbated by your swap being full. Zswap is more of a cache in front of your actual swap; it requires physical swap to function. If the physical swap is full, it cannot receive more data! Zswap not doing very much when the swap is full is totally expected behaviour because it simply doesn't. The solution to that is to size your swap sensibly. (Admittedly, this does not appear to be documented clearly.)

    zswap uses the exact same allocator as zram these days (zsmalloc). It'd be very surprising if it had different space efficiency characteristics. It's not impossible (could be a bug) but claiming so would require quite certain evidence IMHO.

    RE: LRU inversion: the problem with not caring about it is that it's not a visible problem until it very suddenly is. Your system will not gradually degrade but very suddenly and unpredictably hit a wall that it cannot get itself over.

  • source
  • parent
  • context
  • [–] 2 points 6 months ago

    Inconsistent time before sleep is likely the kernel waiting for IO to sync to disk.

    Not going to sleep at all implies a serious issue that prevented the kernel from doing so. Check your logs!

    Suspend reliability greatly depends on the firmware of your specific device as it controls the wakeup.

    On my Framework 16 for instance, it is very reliable these days. I can't remember the last time it woke up unexpectedly and I'm not sure whether it happened even once since the firmware update that fixed a major oversight in keyboard wakeup (waking when a key was pressed through a closed lid).

  • source
  • [–] 1 point 6 months ago

    In Hyprland, how it works is that you define the screen lock command (e.g. swaylock) in hypridle and that gets wired into logind somehow such that you can loginctl lock-session.

    I then (also in hypridle) define a before sleep hook that locks the session.

    I believe the proper way to do this would be to run your lockscreen as a systemd unit that is WantedBy and Before suspend.target. This would in theory take care of making it idempotent and reliably show the lockscreen before initiating suspend.
    A friend of mine has this sort of setup and, while it is reliable, the lockscreen is still racy and sometimes only triggers after suspend. Might be the lockscreen unit not signalling its readiness to systemd properly though.

  • source
  • [–] 2 points 9 months ago (1 child)

    Thank you!

    I've found the Seedstudio thing after posting this too and it looks like the thing I'd be looking for!

    What's your experience w.r.t. coverage?
    Obviously that highly depends on where exactly you are – you certainly aren't going to have coverage in the outback – but I'm mostly concerned with places where people actually go and would take my bag/laptop/bicycle to. 'Stralia is going to generally be quite different from Germany too of course but it would be a good reference point from which I could extrapolate.

  • source
  • parent
  • context
  • [–] 2 points 9 months ago

    The issue is not the instruction set of the processors. That's actually quite well standardised with ARM (albeit unfree) and there is plenty of generic support for it because of that.

    The issue is all the "peripheral" devices such as WiFi, WWAN, display etc. that are wired up in extremely bespoke device-specific ways. They are usually implemented in vendor kernels with millions of lines of divergence to mainline at best and/or proprietary blobs at worst.

    Changing the ISA from one well-supported closed standard to a less well-supported open one will not change that issue one bit.

  • source
  • parent
  • context
  • [–] 1 point 9 months ago

    Try them. That's the only way. Go to an actual physical place (i.e. a store) and see what you like and don't like about the models there.

    Then you can ask for specific advice using those models as a reference.

  • source
  • [–] 2 points 9 months ago (3 children)

    Are there any (ideally waterproof) compact devices with long battery life (months~years)?

    On the website I only found a long list of supported devices with brand name search and protocol type. grep showed no LoRaWAN devices though?

    My use-case is theft tracking. I only need the device to be able to locate itself after a theft actually occurred and I request it remotely. (Perhaps also periodically with very low frequency.)

  • source
  • parent
  • context
  • [–] 3 points 9 months ago (1 child)

    Disabling su is stupid because you always need some form of privilege escalation, restricting sudo to apt offers no security benefit whatsoever as apt allows arbitrary file modification, disabling root ssh provides no benefit when the unprivileged user has sudo access – I could go on.

  • source
  • parent
  • context
  • [–] 3 points 9 months ago (2 children)

    I'd highly recommend you actually read it. Once you look past the LLM-ish phrasing, it quickly becomes clear that the actual information contained is human-made with a great amount of valuable thought put into it.

    I've been here for a long-time (go and check if you'd like). There wasn't a single thing in that post that made me think the author hasn't understood the principles of the fediverse that make it so valuable or reasoned wrong about them – quite the opposite.

    This post idenifies many (if not most) of the major problems that I have had with Lemmy over the years. The onboarding improvements you've seemed to have at least glanced at are just the tip of the iceberg.
    I use Lemmy despite of these limitations but I am also a technical person with quite a bit of tolerance for such technological pain. The high-level improvements proposed here would meaningfully diminish these; allowing less technologically capable or tolerant people to benefit from Lemmy too.

    This is actual UX requirement engineering.

    If broader (and less technical) user adoption is a goal of the Lemmy project, I'd consider the vision outlined in this post to possibly be one of the most valuable non-technical contributions to Lemmy as a whole.
    Seriously.

  • source
  • parent
  • context
  •  

    scrcpy v3.0

    Changes since v2.7:

    • Add virtual display feature (#5370, #5506, #1887, #4528, #5137)
    • Launch Android app on start (#5370)
    • Add OpenGL filters (#5455)
    • Add --capture-orientation to replace --lock-video-orientation (which was broken on Android 14) (#4011, #4426, #5455)
    • Fix --crop on Android 14 (#4162, #5387, #5455)
    • Handle virtual display rotation (#5428, #5455)
    • Add --angle to apply a custom rotation (#4135, #4345, #4658, #5455)
    • Add --screen-off-timeout (#5447)
    • Adapt "turn screen off" for Android 15 (#3927, #5418)
    • Add shortcut Ctrl+Shift+click-and-move for horizontal tilt (#5317)
    • Add shortcut MOD+Shift+r to reset video capture/encoding (#5432)
    • Forward Alt and Super with SDK Keyboard (#5318, #5322)
    • Add more details to --list-encoders output (#5416)
    • Add option to disable virtual display system decorations (#5494)
    • Fix --time-limit overflow on Windows (#5355)
    • Fix "does not match caller's uid 2000" error (#4639, #5476)
    • Accept filenames containing ':' when recording (#5487, #5499)
    • Disable mouse by default if no video playback (#5410)
    • Rename --display-buffer to --video-buffer (#5403, #5420)
    • Listen to display changed events (#5415, #161, #1918, #4152, #5362)
    • Adapt server debugging for Android >= 11 (#5346, #5466)
    • Upgrade FFmpeg to 7.1 (#5332)
    • Upgrade SDL to 2.30.9
    • Upgrade platform-tools (adb) to 35.0.2
    • Build releases via GitHub Actions (#5306, #4490)
    • Release static builds for Linux and macOS (#5515, #1733, #3235, #4489, #5327)
    • Various technical fixes

    Highlights

    Virtual display

    By default, scrcpy mirrors the device screen.

    With this new feature (#5370), it is now possible to mirror a new virtual display, with a custom size:

    scrcpy --new-display=1920x1080
    scrcpy --new-display=1920x1080/420  # force 420 dpi
    scrcpy --new-display         # use the main display size and density
    scrcpy --new-display=/240    # use the main display size and 240 dpi
    

    On some devices, a launcher is available in the virtual display.

    When no launcher is available, the virtual display is empty. In that case, you must start an Android app.

    For example:

    scrcpy --new-display=1920x1080 --start-app=org.videolan.vlc
    

    To list the Android apps installed on the device:

    scrcpy --list-apps
    

    For convenience, you can also select an app by its name using a ? prefix:

    scrcpy --start-app=?firefox
    

    However, retrieving app names may take some time (sometimes several seconds), so passing the package name is recommended.

    On-device OpenGL filters

    Scrcpy can now transform the captured video stream before encoding by applying OpenGL filters directly on the device. This has made it possible to fix several issues and implement new features, as described below (more details in #5455).

    Crop

    The --crop option was broken for devices running Android >= 14 (#4162). It has been reimplemented using OpenGL filters internally.

    Its usage remains the same:

    scrcpy --crop=800:600:100:100
    

    It now also works for camera and virtual displays.

    Capture orientation

    The --lock-video-orientation option was broken for devices running Android >= 14 (#4011).

    It has been replaced by a more general option --capture-orientation, implemented using OpenGL filters:

    scrcpy --capture-orientation=0
    scrcpy --capture-orientation=90       # 90° clockwise
    scrcpy --capture-orientation=180      # 180°
    scrcpy --capture-orientation=270      # 270° clockwise
    scrcpy --capture-orientation=flip0    # hflip
    scrcpy --capture-orientation=flip90   # hflip + 90° clockwise
    scrcpy --capture-orientation=flip180  # hflip + 180°
    scrcpy --capture-orientation=flip270  # hflip + 270° clockwise
    

    The capture orientation can be locked by using a @ prefix, so that a physical device rotation does not change the captured video orientation:

    scrcpy --capture-orientation=@         # locked to the initial orientation
    scrcpy --capture-orientation=@0        # locked to 0°
    scrcpy --capture-orientation=@90       # locked to 90° clockwise
    scrcpy --capture-orientation=@180      # locked to 180°
    scrcpy --capture-orientation=@270      # locked to 270° clockwise
    scrcpy --capture-orientation=@flip0    # locked to hflip
    scrcpy --capture-orientation=@flip90   # locked to hflip + 90° clockwise
    scrcpy --capture-orientation=@flip180  # locked to hflip + 180°
    scrcpy --capture-orientation=@flip270  # locked to hflip + 270° clockwise
    

    Now, it also works for camera (fixing #4426) and virtual displays.

    Custom rotation

    A new option --angle allows to rotate the content by a custom angle. Combined with --crop, this is especially useful for mirroring the Meta Quest 3 (#4135, #4345, #4658).

    Virtual display rotation

    The new virtual display feature initially could not rotate. The rotation has been implemented using OpenGL filters.

    (That is what triggered the development of OpenGL filters.)

    Like previously, the current app can be rotated by MOD+r (shortcuts).

    Screen off timeout

    The existing option --stay-awake only keeps the device awake *while it is plugged in, meaning it typically does not work over TCP/IP.

    A new option, --screen-off-timeout, modifies the screen-off timeout setting while scrcpy is running and restores it on exit:

    scrcpy --screen-off-timeout=300  # 300 seconds (5 minutes)
    

    Static builds

    For convenience, static builds are now provided for Linux and macOS (#5515).

    More targets might be added in the future.

    This is still experimental for now, so if you encounter problems, please report them.

    Features you might have missed

    If you haven't tried scrcpy in a while, here are some features introduced in the 2.x versions that you might have missed (check the release notes to each version for more details):


     

    Josef Bacik who was working on this said:

    I fixed up all your review comments, but yes we don't care about this internally anymore so it's been de-prioritized. I have to rebase onto the new stuff, re-run tests, fix any bugs that may have creeped in, but the current code addressed all of your comments. Once I get time to get back to this you'll have a new version in your inbox, but that may be some time.

    (Note: This was back in April.)

    submitted 2 years ago by to c/btrfs@lemmy.ml
     

    Hi,

    there are mostly stabilization, refactoring and cleanup changes. There rest are minor performance optimizations due to caching or lock contention reduction and a few notable fixes.

    Please pull, thanks.

    Performance improvements:

    • minor speedup in logging when repeatedly allocated structure is preallocated only once, improves latency and decreases lock contention

    • minor throughput increase (+6%), reduced lock contention after clearing delayed allocation bits, applies to several common workload types

    • skip full quota rescan if a new relation is added in the same transaction

    Fixes:

    • zstd fix for inline compressed file in subpage mode, updated version from the 6.8 time

    • proper qgroup inheritance ioctl parameter validation

    • more fiemap followup fixes after reduced locking done in 6.8

      • fix race when detecting delalloc ranges

    Core changes:

    • more debugging code

      • added assertions for a very rare crash in raid56 calculation
      • tree-checker dumps page state to give more insights into possible reference counting issues
    • add checksum calculation offloading sysfs knob, for now enabled under DEBUG only to determine a good heuristic for deciding the offload or synchronous, depends on various factors (block group profile, device speed) and is not as clear as initially thought (checksum type)

    • error handling improvements, added assertions

    • more page to folio conversion (defrag, truncate), cached size and shift

    • preparation for more fine grained locking of sectors in subpage mode

    • cleanups and refactoring

      • include cleanups, forward declarations
      • pointer-to-structure helpers
      • redundant argument removals
      • removed unused code
      • slab cache updates, last use of SLAB_MEM_SPREAD removed
     

    cross-posted from: https://programming.dev/post/9319044

    Hey,

    I am planning to implement authenticated boot inspired from Pid Eins' blog. I'll be using pam mount for /home/user. I need to check integrity of all partitions.

    I have been using luks+ext4 till now. I am hesistant hesitant to switch to zfs/btrfs, afraid I might fuck up. A while back I accidently purged '/' trying out timeshift which was my fault.

    Should I use zfs/btrfs for /home/user? As for root, I'm considering luks+(zfs/btrfs) to be restorable to blank state.

    view more: next ›