‹ BackHN Continuity

Thread

Fakecloud: Local AWS cloud emulator for integration tests

154 points · 78 comments · theanonymousone

  1. otterley · · focus · HN ↗
    There’s also MiniStack, which forked from LocalStack after they started breaking developer workflows: <a href="https:&#x2F;&#x2F;ministack.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ministack.org&#x2F;

    Both fakecloud and its website look sloppily vibe-coded, and its “authors” are anonymous. It’s going to take a while for it to earn trust. I’d treat it with suspicion. (Curl-to-shell pipe to install? Ugh.)

    1. straygarr · · focus · HN ↗
      Agreed with everything up to:

      &quot;curl-to-shell pipe to install&quot; - what&#x27;s the problem here? that&#x27;s pretty common on linux systems and something the AWS CLI uses.

      Or is the problem the fact that this dev is untrusted and is executing a possibly malicious script on your machine?

      1. ssl-3 · · focus · HN ↗
        The problem, for me, is that self-running installers can create a mess that&#x27;s hard to keep track of.

        I&#x27;ve run Linux without meaningful package management, as that was kind of the style of the time 30 years ago with Slackware. It can quickly become untenable.

        There&#x27;s no real difference between an uninspected script that gets piped straight from the URL into the shell, or a similarly-uninspected make&amp;&amp;sudo make install routine from a tarball. They can both execute code that does bad things (whether unintentionally or deliberately), and they can both leave a mess that is hard to cleaned up.

        I&#x27;ve found that it is better to just avoid going down that road to begin with. Whether distro-specific packages, Docker containers, flatpaks, or whatever: All of these make housekeeping easier.

        1. giantrobot · · focus · HN ↗
          &gt; The problem, for me, is that self-running installers can create a mess that&#x27;s hard to keep track of.

          For reasons my machine with a beefy GPU is stuck on an older set of Nvidia drivers. I&#x27;ve got them pinned with apt. The ollama installer fucked everything up by updating stuff that apparently wasn&#x27;t pinned. After I had fun cleaning up that fucking mess I found it overwrote my custom systemd service file so I had to go in and fix that.

          Curl-to-shell is a bullshit antipattern. I have no interest in going back to the dark days of expanding tarballs to &#x2F; and hoping for the best.

          1. ssl-3 · · focus · HN ↗
            Right. I&#x27;ve done the same.

            And when the new distro-provided nVidia driver does something garish like, say, break XFCE, then it&#x27;s easy(ish) to roll it back using distro tools and pin it there. After that, just wait until some other more-functional combination of shakes loose in the distro channel.

            When a new nVidia driver shows up that promises a fix but the distro hasn&#x27;t packaged it yet, then the temptation to just download and run the installer that&#x27;s on nVidia&#x27;s website. But using nVidia&#x27;s special-sauce installer taints the system in ways that distro tools deliberately seek to avoid.

            And: Oh, man. I&#x27;d almost forgotten about the binary tarballs that were intended to be simply dumped into &#x2F;, where they&#x27;d just tromp on whatever. Sure, it was fast. And for some people, some times, it even worked. Sometimes, it didn&#x27;t work. Other times, it broke other things that had been working. And it left a mess behind every single time.

            A little bit of a mess isn&#x27;t necessarily devastating on a personal system. But the mess accumulates every time such an unmanaged installation process happens until it eventually overwhelms to the point that even the most functionally-disorganized of people become dysfunctional.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.