• 0 Posts
  • 20 Comments
Joined 5 days ago
cake
Cake day: March 15th, 2026

help-circle
  • From their wiki:

    What Makes Vostok Different? Void Linux is powerful — but it requires effort to set up. Vostok removes that barrier entirely:

    • KDE Plasma out of the box — a full, polished desktop environment ready from the first boot
    • Everything pre-configured — codecs, drivers, browser, fonts — all included
    • Vostok Repository — hundreds of additional packages not available in the official Void repos (Brave, Figma, and more)
    • Beginner-friendly, expert-approved — simple enough for newcomers, powerful enough for professionals
    • 100% free — no subscriptions, no telemetry, no corporate strings
    • One developer, one vision — transparent, independent, and built with love for the community
    • Open to everyone — developers, designers, gamers, students, sysadmins — Vostok is for all of them

    The em dashes definitely gives me LLM-vibes. Regardless, it mostly comes over as Void Linux with KDE Plasma and some onboarding. And I suppose they have their own repository. Furthermore, I think it’s a very new distro as their Github activities only go two months back.

    To OP: Why would you use this over (some) other Void derivatives? Secondly, as you state

    I can customize it myself

    Why even bother with any of these?



  • Should I just run all these updates as they come up?

    For best practices related to security, yes.

    Do you all run these updates as they pop up?

    I’m on a Fedora-derivative that does automatic updates in the background. It applies those at least once a day.

    Are you all getting this many updates on Fedora

    Yes. This is standard procedure on all (semi-)rolling release distros.

    or is it something specific to me and the apps I’m running?

    Nah.

    Is there a way to de-select some updates if I don’t want to run all of them?

    I believe it’s possible. But this Fedora maintainer mentions the following (and I quote):

    “Fedora is a major-version stable system, which means that it isn’t guaranteed safe to cherry-pick updates. The only reliable state for a major-version stable system is “fully updated”. While rpm can detect major-version changes in dependencies, it doesn’t detect minor-version changes in dependencies. That means that a package that you cherry-pick might appear to have all of its dependencies met from rpm’s point of view, but it might crash at runtime because those dependencies don’t have features that are required by the application.”

    Should I ignore daily updates

    It’s your PC. You do you. I would personally advise against it.

    and install them less frequently, say monthly?

    I have noticed that updating once every couple of days is relatively standard. I suppose it’s ‘fine’~ish as long as it doesn’t exceed two weeks. But monthly would definitely be stretching it. At that point…, perhaps considering a distro with a slower release cadence makes more sense.

    Meaning, I’m not super interested in being the glitch finder. If there’s a bug in an update, I’d rather have somebody else find it first and have the update patched.

    So…, if that’s what this is all about, then the following is worth noting:

    • On Fedora, there’s the so-called Rawhide branch. This is basically their unstable branch and where most of the actual testing happens. You’ll (mostly) only receive updates that have already been tested in Rawhide. So, bugs/glitches and whatnot are pretty rare.
    • But, if this is still your concern, then perhaps you should consider a distro with a slow release cadence. Which, basically comes down to picking one between Debian (on the Stable branch), openSUSE Leap and Ubuntu.








  • I could see it becoming the future. But only under a couple of scenarios.

    Scenario A: It becomes (strictly) better and/or easier than the alternative. Kinda like how systemd effectively replaced SysVinit within a couple of years, simply because it was a more sane alternative. But this is reliant on the read-only aspect being put in place without affecting existing workflows on traditional distros. So, as Fedora Atomic is the atomic distro I’m most familiar with, I’ll provide explicit examples from it:

    • Installing packages shouldn’t take a reboot to take effect. I can see sysexts being leveraged for this eventually.
    • Any commands that involve dnf should (somehow) continue to function. It could even be an alias (or something) that invokes something else entirely. I don’t even think most users will care for what exactly happens in the background, as long as the functional expectation is being met.
    • The previous two points shouldn’t come at a (significant) speed loss.

    Scenario B: It’s enforced on us by (some of) our Linux overlords and/or expected by (parts of) the Desktop Linux stack. Kinda like how the GNOME desktop environment currently has dependencies that are systemd-components. Thus, requiring some hacking to make it work in its absence. Currently, I can only see some RHEL(-adjacent) projects committing to this.

    But I think both of the above scenarios are at least 5 years away. While atomic/immutable distros enjoy a healthy (perhaps even generous) amount of development, AFAIK none of them are actually 100% feature-complete[1] compared to their traditional counterparts. So, fixing (most of) the remaining edge cases to make migration possible for every enthusiast that even considers switching, should probably be their priority.


    1. To be clear, it’s probably at like 95% or so. ↩︎


  • I didn’t really mean it in the sense that the communities of different atomic/immutable engage regarding the trade-offs associated by their respective methods of achieving atomicity/immutability. And, honestly, I’d actually love to see more of that. Even if NixOS users would dunk on the rest, at least until the learning curves are brought up.

    Instead, what we often find are unproductive threads like this one 😅. In which, naysayers and proponents act like they’re engaging, but I simply fail to understand what’s happening.






    • Step 1. Upgrade to proactive security. Projects like HotCakeX’ offer a streamlined method of attaining it.
    • Step 2. Commit to best practices. There’s a long list of this, but the short of it would be:
      • Uphold a strong backbone of secure software that has proven to be committed to safe practices.
      • Ensure that your system and/or software is always up-to-date.
      • Don’t visit unsafe/untrusted websites. Don’t click on shady/untrusted links.
      • Don’t execute untrusted/unsafe files. Especially not with administrator’s rights.
      • Sandbox all activities. So that even if you’re compromised, that the adversary can only access very little beyond the binary/program/software itself.



  • atomicStan@programming.devtoLinux@lemmy.ml*Permanently Deleted*
    link
    fedilink
    arrow-up
    16
    arrow-down
    2
    ·
    edit-2
    4 days ago

    You seem to have the false notion that corporate distros are safe (or something). But, that’s not true. Look e.g. at the demise of Clear Linux OS.

    For (perhaps) a better assessment on whether a distro is well-established[1] or not, consider looking at the following factors:

    • How long does it exist? Like, if it’s old enough to drink, then that’s definitely a good indication.
    • How strong is its community? If there are literally millions of users, many of which actively contribute, then that’s definitely a good thing.
    • How active is its development? The Linux landscape is constantly evolving. Hence, adopting changes (or, at least, enabling them) is somewhat to be expected.
    • Does it serve a distinct raison d’être? It simply has to offer a strong justification for its existence.
    • Does it have any strong dependencies/contingencies? Here, a lack thereof is actually what’s good.

    TL;DR: If you want to be absolutely safe, then I’d recommend Arch, Debian or Gentoo.


    1. I.e. that it will not cease existing overnight. ↩︎