• 326 Posts
  • 4.88K Comments
Joined 3 years ago
Cake day: July 7th, 2023
  • just_another_person@lemmy.worldtoLinux@programming.dev•openRuyi — A Linux Distribution for RISC-V
    17·
    9 days ago

    I don’t want to be a downer here, but this is the same BS funds gathering as everything that wants to be a “gaming” distro.

    Unless you can show there is a FUNDAMENTAL difference in the way this operates versus others, this is bullshit.

    The upstream Linux kernel provides the driver layer for all CPU and SOC compatibility. There is no wiggle room here with custom modules to support the basic thing that bootstraps everything else.

    This distro isn’t even claiming they have some IP that makes this somehow geared towards RISC-V, when all you have to do is target that architecture and ensure packages you install are cross-compiled for that very same architecture.

    This is some nonsensical branding bullshit. If I claimed to make a distro for a hardware platform that operates 1000’ above Sea Level, I had better show up with some benchmarks, stats, and reasoning why this matters at all.

  • just_another_person@lemmy.worldtoLinux@programming.dev•GabeN Is Shitting Yacht Money into Flatpak and You're Still Arguing Init Systems
    41·
    1 month ago

    I don’t really get the point of the blog, honestly, because in the first part they are railing against one angle, then reverse and argue FOR it in a sense by saying Flatpak just works. Of course it does. That’s it’s job.

    AppImage also just works, but there is a fundamental difference in the delta of what you get as a payload. AppImage has EVERYTHING the image needs to run. Flatpaks only contain the running code and custom dependencies, then it’s manager solves for shared libraries and generics from commonly available layers to download and run to solve for those deps.

    Both make sense depending on how you feel you need to tackle the problem.

    Where the author kid of goes off the rails is complaining that somehow either camp is somehow responsible for their product being popular enough to survive and be taken up by Valve. In this specific case, Valve is intending to include simple packaging for games and libraries they intend to ship to millions of cross platform devices. Flatpak makes sense from a bandwidth and storage standpoint for end-users.

    AppImage does not. No idea why this person is taking issue with that.

  • just_another_person@lemmy.worldtoLinux@programming.dev•My shitty tutorial (How I do it): How to "download" more memory on linux
    21·
    2 months ago

    Not trying to shit on your idea here, but this is actually going to make your systems much less performant in a number of ways. Let me explain why.

    The Linux kernel memory scheduler is extremely good at what it does. It’s probably the reason why Linux crushed adoption into the server market so rapidly 20+ years ago. Not only is it fast, it’s super smart.

    The process scheduler is also top-tier, with BSD only sliiightly maybe winning out in some edge cases because it takes more resources into consideration when planning executions. This is why BSD wins out in the network performance category so often (until very recently).

    All of that to say, if you have enough memory to hold whatever you need to run in memory, everything runs great. Cut to you not having memory, and needing to swap.

    Once swap enters into the fray, the performance of both memory and process scheduling drops exponentially depending on the number of running processes. For each extra process needing more memory, the rest of the system takes a hit from the interrupt needed to find and clear cached pages, or allocate swap. This is called Memory Contention.

    Memory Contention engages a whole host of different levera in various parts of the kernel. The more you have, the more CPU cycles you use to solve for it, and you also increase wait time for everything in the system from I/O interrupt at the process scheduler.

    What you’re doing by enabling BOTH swap and zram in the way you are increasing the workload of the kernel by a factor of two, so twice the amount of effort at the CPU, and twice the amount of I/O wait when contention comes into play. It’s just not performant, and it’s wasting energy.

    They both deal with swap, just either at the disk or available allocated RAM space, and you’re just making your machine do extra work to figure out where it should be swapping to.