Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We built the fastest CI and it failed

earthly.dev

Post reply on HN
Print view View original

271–280 of 301 posts

Re: We built the fastest CI and it failed

#271

Post by lelanthran »

BoorishBears wrote: post #270
lelanthran wrote: post #261

Earlier quoted context omitted.

> At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag). Can you explain more about how this works for SSO? Let's say I'm trying to launch a product (which I am), and want to have SSO as part of the package (which I do), how do I implement what you just said? I looked into SSO services and they're bloody expensive…

Their reply is not SSO, it's some toy alternative they're proposing that none of your customers would accept (like saying "Dropbox is just rsync") SSO is hairy enough that you can't write it from scratch in any reasonable amount of time for what a typical SaaS needs. There's OSS SSO you can host yourself that supports enterprise : https://www.keycloak.org/ If you're B2C Firebase Auth is cheap, and doesn't actually re…

> SSO is hairy enough that you can't write it from scratch in any reasonable amount of time for what a typical SaaS needs.

I expected so, looking at how much it costs to provide just SSO as a service.

Thanks for keycloak, didn't know about that.

Re: We built the fastest CI and it failed

#272

Post by Xymist »

gabereiser wrote: post #158
justin_oaks wrote: post #145

Earlier quoted context omitted.

I know these are examples, so I don't want to pick on you too much, but I have one nitpick: Reserving SSO for enterprise customers is awful. Please don't do it. See https://sso.tax/ for details but I'll quote this from it "SSO is a core security requirement for any company with more than five employees"

If you have more than 5 employees, I’m sending you a sales rep to sell SSO to you.

If I have to go through a sales rep to try or buy your product, I'm going with a competitor. Zero touch is a feature, upsell opportunities are cancer.

Re: We built the fastest CI and it failed

#273

Post by belmont_sup »

tazjin wrote: post #175
JustLurking2022 wrote: post #173

Earlier quoted context omitted.

Seriously, is there an email distro or something to notify Nix users when there's a new post to go troll? It's not suitable for 90%+ of users, which seems a far cry from superior.

It's just very noticeable when half of what the industry seems to spend its time on is solved problems. You and all the others have to learn why touching the hot stove is a bad idea the same way most children do. It's frustrating to observe. It's fine to criticise Nix for its various flaws, but any suggestion of an "alternative" that has learned nothing from it is just a collective waste of time.

I’ve recently had to learn some nix to build an IHP app (Haskell framework). Most hosting providers require a dockerfile and/or image. I couldn’t get nix to build an image on time within the hosting providers’ CI. So I gave up.

For any other project, I can spend half an hour max to get a decent deployable build. The trade offs is Nix doesn’t seem to work for me.

Re: We built the fastest CI and it failed

#274

Post by pdimitar »

tazjin wrote: post #175
JustLurking2022 wrote: post #173

Earlier quoted context omitted.

Seriously, is there an email distro or something to notify Nix users when there's a new post to go troll? It's not suitable for 90%+ of users, which seems a far cry from superior.

It's just very noticeable when half of what the industry seems to spend its time on is solved problems. You and all the others have to learn why touching the hot stove is a bad idea the same way most children do. It's frustrating to observe. It's fine to criticise Nix for its various flaws, but any suggestion of an "alternative" that has learned nothing from it is just a collective waste of time.

> You and all the others have to learn why touching the hot stove is a bad idea the same way most children do. It's frustrating to observe.

You say that while your ecosystem still can't get away from cutesy childish terms like "flakes" and "pills". Newsflash: nobody cares. I want "a package" and "a system".

I am not impressed. Before you look down on others make your own thing look uber-professional and then uproot any and all nerd-friendly marketing from it, now and forever. "It was in fact just a phase, mom" -- that's the aura that Nix should radiate before I give it a second chance.

Nix is supposed to solve a very serious problem and if it actually succeeds in that technical goal, the next step is for them to act like it. Very often you're marketing to CTOs or other tech executives -- working programmers are only one chunk of your audience. So that ecosystem has to do better -- starting with you. Your two comments here are basically a text-book argument against using Nix.

I've been a CTO and VP of Eng and I have skipped projects that can't sound professional. I know I have missed out on good stuff; I am very well aware. But we all have only 24h in a day, and only so much energy. We have to filter. One of my filters is: perceived / marketed professionalism.

(To be fair to all sides, I like the nixos.org website. I don't like practically anything else about the ecosystem though.)

> It's fine to criticise Nix for its various flaws, but any suggestion of an "alternative" that has learned nothing from it is just a collective waste of time.

Let's start with that one: nobody needed one more programming language. Nobody will "see the light" if every new technology requires one more knowledge investment. Somebody must tell you that programmers, DevOps, full-blown Ops, CTOs etc. are already overworked and already have to know and regularly catch up with way too much.

If Nix is aiming to help people work less on very annoying problems then it should, you, actually make them work less.

Nix's marketing is a complete mess. "We want you to think less about A and B so here, now learn, X, Y, Z and you should still know A and B -- but it gets better after, one day!".

Nah.

It's fine that you found technology that you love but your bias is very clearly visible and you lack the introspection skills to see that Nix is not that impressive.

Give me a `curl ... | bash` installer plus instant onboarding plus zero upkeep (an oft complaint about Nix btw) and I am sold. Anything less than that, to me you are just one more voice in a huge crowd where everyone screams "use my thing, it's amazing!".

Differentiate yourself and people will flock to you without you having to lift a finger. The fact that this hasn't happened yet is a strong hint that Nix fans are refusing to notice and take a lesson from.

Re: We built the fastest CI and it failed

#275

Post by fhaldridge7 »

shepherdjerred wrote: post #79
KETpXDDzR wrote: post #23

> 2-20X faster builds This appears several times over the whole article. What are you comparing to? Without any baseline, this phrase is worthless marketing gibberish.

Uncached, unparalleled builds running on other platforms.

probably running on shared free runners of other platforms

Re: We built the fastest CI and it failed

#276

Post by marcosnils »

geggo98 wrote: post #263
shykes wrote: post #252

Earlier quoted context omitted.

> Dagger devs have de facto abandoned that language entirely in favor of churning out SDKs for the most popular programming languages— all imperative, all Turing-complete, and all, imo, bad fits for the space. Disclaimer: I’m the CEO of Dagger. You’re right that we offer SDKs for popular languages, which happen to be imperative. But Dagger remains a declarative system, so what you liked about the earlier versions is…

While you are here: the Node.js syntax highlights on you QuickStart docs seems to be broken. Tested with Safari and Chrome on a recent macOS. That’s not a huge issue, but makes it a bit harder to grasp what’s going on and how the Dagger SDK actually works.

Thx for reporting. We'll fix ASAP

Re: We built the fastest CI and it failed

#277

Post by yencabulator »

danudey wrote: post #61
theamk wrote: post #19

Earlier quoted context omitted.

except not really.. their tutorial [0] includes no-compile languages like python and JS, with only non-trivial compilation being and Java... and how do they do it? RUN gradle build At least in this case, Earthly has no insight into how repository is organized, and it _will_ recompile the entire repository with every single commit. So what's the real value of it? this basically seems like a better "docker build" alter…

That's step one, 'how to write a basic Earthfile that just does the thing', so they don't delve into the details of caching and how it works, but look at the whole block and not just that one line; it operates like a Dockerfile: build: COPY build.gradle ./ COPY src src RUN gradle build RUN gradle install SAVE ARTIFACT build/install/java-example/bin /bin SAVE ARTIFACT build/install/java-example/lib /lib The COPY phase…

That only splits dependency-build from app-build. Any change to the app source code still causes a full rebuild, unless you figure out how to share the cache directory between builds (and then parallelism gets sketchy).

Generic CI just simply can't parallelize+cache on a level comparable to systems that understand the build itself (Bazel, sccache, etc).

Re: We built the fastest CI and it failed

#278

Post by yencabulator »

esafak wrote: post #38
bluGill wrote: post #25

Earlier quoted context omitted.

Sure, but you have to be 100% perfect in guessing when the cache file must be rebuilt. If there is any situation at all where you use the cached file when you should have rebuilt your tool is not useful. Note that you can go too far. If you rebuild a file on linux even though the only changes were in a "#ifdef freebsd" (windows, mac...) section that is a waste of time, but not harmful. However we already have tools t…

This is a solved problem; modern build tools and workflow orchestrators face the same challenge. You declare your inputs for a given task and cache the output as long as the inputs are unchanged, as determined by their hash. So there is no wrong guessing, only an incomplete specification of inputs. It's an elegant solution, if I do say so, and has worked well at companies I've seen it used.

Where that world sucks is that it forces you to ignore or duplicate work from the native build system. E.g. Go or Rust know which source files are needed to build something, yet Bazel makes you write that out.

No, generating the file isn't "the fix" if you're still committing those generating files into the source control; that's still duplication and manual labor.

Re: We built the fastest CI and it failed

#279

Post by yencabulator »

SkyPuncher wrote: post #34

Unless CI is _really_ painful, it's just not that painful. I spend a day cursing about my build when I spin up a new project, then I forget about it for months. Specs run fast enough - especially locally where I only run failing or known-modified specs.

Last job where I worked on CI infrastructure, I set up a 200-machine physical server farm, that was then split on-demand into smaller clusters, and those ran tests for a distributed storage product -- including day-long stress tests.

If you have trivial needs, trivial solutions are sufficient.

Re: We built the fastest CI and it failed

#280

Post by rewmie »

SoftTalker wrote: post #227
rewmie wrote: post #129

Earlier quoted context omitted.

> Not to rain on the parade here but this is literally a copy-pasta product. More to the point, the product offered no compelling reason to use it, let alone pay for it. Being "fast" is not a selling point. Developers don't want slow pipelines, but that does not mean they want fast pipelines. The speed that the pipeline works is more depending on how the pipeline is setup than the overhead of the pipeline service, an…

> Being "fast" is not a selling point It could be, if that is a pain point for the customer. You could be 10x faster than any other option, but if "slow builds" are not on the top 10 list of problems they are dealing with, it's a meaningless statistic.

> It could be, if that is a pain point for the customer.

But is it, though?

I mean, are any of the competing CICD services noticeably slow, specially if we focus on the system's overhead?

I don't think there are, at all.

We're talking about at best millisecond differences in workflows that take minutes just to do the things we tell them to, such as setting up a build environment.

Post reply on HN