Flatcar

Flatcar project repository for issue tracking, project documentation, etc. (by flatcar)

Flatcar Alternatives

Similar projects and alternatives to Flatcar

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better Flatcar alternative or higher similarity.

Flatcar reviews and mentions

Posts with mentions or reviews of Flatcar. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-04-14.
  • Linux fu: getting started with systemd
    5 projects | news.ycombinator.com | 14 Apr 2024
  • Bottlerocket – Minimal, immutable Linux OS with verified boot
    6 projects | news.ycombinator.com | 23 Sep 2023
  • Wolfi: A community Linux OS designed for the container and cloud-native era
    10 projects | news.ycombinator.com | 27 Jun 2023
    Sounds like you're looking for the CoreOS Linux successor FlatCar https://www.flatcar.org/

    It's actually based on some ChromeOS update tools under the hood but is a regular Linux distro, just super minimal and designed to run containers.

  • Flatcar Container Linux
    1 project | /r/patient_hackernews | 9 Apr 2023
    1 project | /r/hackernews | 9 Apr 2023
    1 project | /r/hypeurls | 9 Apr 2023
    1 project | /r/CKsTechNews | 9 Apr 2023
    14 projects | news.ycombinator.com | 9 Apr 2023
    I guess if you found my comment to be "comically hyperbolic" then replying to mine with a "comically reductionist" is fair game

    So, anyway, I actually did dig up a concrete example of my experience with it, and I cannot link to the "Additional information" section but that is both why I think the thing was a mess and also why the Miroservices YT joke resonated: https://github.com/flatcar/Flatcar/issues/220

    I think the CoreOS boot strategy was decomposed into a bunch of different executables, each responsible for doing their own little slice of the world. Maybe it drew inspiration from systemd in that way. But, just like my real life experience with microservices, it requires keeping a bunch of different projects and their upgrade paths in ones head, knowing their disparate config formats, and when one of them inevitably has a bug, understanding how to troubleshoot what went wrong with the system as a whole

    And, again in trying to be reasonable in this discussion[1] I do also understand why one would opt for the data URI, given how much of the rest of Ignition loads content from URLs. I don't believe cloud-init has that remote content paradigm baked into in nearly the same way, so I hear you about that.

    And yes, my belief is that JSON is a data-exchange format from _computer to computer_ and making people write them is a poor DX choice, IN MY OPINION. And, to reiterate, I know that CoreOS's perspective is that it is a computer-to-computer transmission from the transpiler-project-o-the-day to the Ignition binary, but that is predicated on one having access to that transpiler binary in all cases, which is quite different from the problem that cloud-init is trying to solve

    fn-1: I'm sorry you got hurt by my "tire fire" outburst, and that evidently derailed this whole interaction, but it was my experience

  • An overview of single-purpose Linux distributions
    4 projects | news.ycombinator.com | 17 Feb 2023
  • Linux Distro for Running Docker Containers in VM - Ubuntu, Alpine, or...?
    5 projects | /r/Proxmox | 25 Jul 2022
  • A note from our sponsor - SaaSHub
    www.saashub.com | 26 Apr 2024
    SaaSHub helps you find the best software and product alternatives Learn more →

Stats

Basic Flatcar repo stats
20
627
7.5
9 days ago

Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com