also forgot to mention that 90% of the work (and time) is bouncing markdown files back and forth until the design is clear and I feel happy about it. design docs, working docs, etc. implementing then is where I can engage way less and switch to a different tab in cmux to drive it
im finding it way way more "flowy" than pre-ai. all the boring trivia is gone, i can focus on what i actually care about - the shape of what i am building, tradeoffs, second- and third-order consequences of decisions.
the trick to get it uninterrupted is "selective multitasking". i don't like having too many Claudes / Codexes in parallel on auto-pilot; this way im finding i'm getting _something_ that is perfectly plausible, but rarely what i wanted. but I have N going at any given time, just enough to be basically non-stop reading. problems need to be related; within one project, ideally adjacent areas that are complementary. then my "flow" is just switching between reading and typing non-stop. never felt time flying by faster in my life, pure flow
Hi HN - one of the founders of Digger here, the company behind Project OpenTaco.
Allow me to explain the initiative. Under per-run and resources-under-management pricing models many organizations have adopted workarounds and shortcuts that slow the growth of IaC adoption, and are incredibly frustrated by the arrangement. ([1], [2])
But wait - what about OpenTofu?
With OpenTofu, the community already has a credible open-source CLI alternative to BSL-licensed Terraform by Hashicorp. However that only solves half the problem: while the CLI helps teams avoid lock in to BSL licensed Terraform, it doesn’t address governance or collaboration challenges at scale any bigger than a single laptop. That's what TACOs are for; but so far, no open source project was able to challenge Terraform Cloud / Terraform Enterprise.
This is what led to the idea behind project opentaco. The project aims to add the missing enterprise workflows (currently proprietary and extractively priced) to Terraform and OpenTofu: secure remote runs, granular access controls, automated drift detection, enterprise SSO, and stack management, to be delivered as an open, self-hostable tool.
We feel this is Terraform’s “backstage” moment. Backstage did for Internal Developer Portals what we believe Project OpenTaco will do for IaC automation. Before Backstage, enterprises had scattered service catalogs and homegrown portals; Backstage created a standard, defined the category of IDPs, and won adoption at some of the world’s most recognizable companies [3]. We are building OpenTaco to follow the same path for Terraform and OpenTofu orchestration as the open standard.
We’re happy to launch v0.0 today (demo here [4], docs here (5)), you can try it starting today, we’d love any and all feedback!
Yeah the ultimate impact of LLMs might be the end of SEO and copywriting. Rhetoric is cool again, as in skill to convey as much meaning as possible using as little words as possible. "Content" was always a bit of a silly term: the inherent value of it is always negative (proportionate to size), offset by the new knowledge conveyed in a piece. The attention economy is collapsing right in front of our eyes.
I feel betrayed after reading the first few sentences. No human ever would write like this:
"Qatar Airways has taken the future of in-flight connectivity to greater heights by operating the world’s first Starlink-equipped Boeing 777 aircraft..."
"Qatar Airways has just made aviation history by launching the world's first Starlink-equipped Boeing 777 flight. This groundbreaking development promises to revolutionize how we stay connected at 35,000 feet. Let's dive into what this means for travellers!"
Why Claude 3.5 Sonnet is missing from the benchmark? Even if the real reason is different and completely legitimate, or perhaps purely random, it comes across as "claude does better than our new model so we omitted it because we wanted the tallest bars on the chart to be ours". And as soon as the reader thinks that, they may start to question everything else in your work, which is genuinely awesome!
If I'm building something new, or launching a startup, there is not much benefit from encouragement. I don't want to hear "well done, this is so cool".
I want to know as many flaws that I might have overlooked as possible, as quickly as possible - so that in the (highly likely) event that my idea is fundamentally flawed, I can move on to smth else instead of keeping wasting time on it.
it's anything but trivial (otherwise we wouldn't ask); the case for not following certain feature requests goes roughly like this: are those potential users asking for a new feature _same people_ as your ICP or _different people_?
If the former, as in one can imagine an actual person using both features A and B, then obviously, you should ship what users are asking for. But if they are different people - meaning that no one person would use both A and B - then instead of making product better for your customer base, you'd be making the product available to more people. Which conventional startup wisdom advises against (YC, lenny, etc because one can ask - why are the remaining people who need A not using your product yet? It's either product not good enough (then you should improve the product for group A first), or the group A too small (then why do A at all and not focus on B?)
Now, with multiple CI backends is not clear-cut at all. We keep debating this internally but seeing both sides of it. On the one hand, it's highly unlikely that an organisation is using multiple CI tools simultaneously. But then how do we know that GitHub Actions is the one? We are self-hostable commercial oss and one of the selling points over Terraform Cloud is security. This seems to be naturally aligned with Gitlab as customers who'd use a self-hosted VCS are probably our perfect targets. And then the case against Bitbucket is that it's kind of fading away, there are still people using it but their share is definitely not growing, somewhat similar to say Travis or Circle.
This is super cool. Private runners are often so much cheaper, especially in large teams. Comes with a "fat tail" of reliability risk though: taking maintenance of runners means that that say 0.01% of builds would be failing for unknown reasons and it'd take significant effort to fix those. But then again that'd probably be only relevant in large organisations which likely have bigger bottlenecks in their devops practice than that; and if that's just about cost then a no-brainer.
Because of that bucket of problems people end up using these tools to manage terraform runs (also known as TACOs). Terraform Cloud is one of them; there's also Spacelift, Atlantis and a bunch of others covering various aspects of what terraform the language doesn't handle natively (ci/cd, state, tfvars management, dependencies, etc).
At the core though, this seems to boil down to a multi-graph comprised of states with some extra stateful pieces on top, like TFVars, inputs/outputs etc. All that's needed is a reliable service that manages these stateful bits in a manner that supports security and compliance needs (secrets stored safely, audit trail, etc). Currently all that is either not there at all, or part of a large "package offering" like Terraform Cloud or Spacelift.
The case I'm making is that this "logical core" needs to exist in a way that's not coupled to a do-it-all cloud-based solution. It probably should not be part of the language itself; but also shouldn't be an all-or-nothing proposition. Hence the VM / runtime parallel
Another parallel to express a similar concept could be "instrumentation for terraform" - it'd be odd if all the observability tooling for a particular language (say Java) were coupled to a cloud-based offering by the company that created said language (Oracle) right? There's a bunch of stuff outside of Java that most Java applications need nevertheless - like application server (eg Tomcat) and so on. Okay that's not exactly instrumentation; but then logging tools, monitoring tools, etc.
I took the definition from Lightspeed's OSS GTM workshop that was held in May this year. Upon further googling, it appears that a broadly accepted meaning of "fauxpen source" is indeed different. Thank you!
We are beyond excited to be part of this great initiative. We did of course expect a fork to be of significant interest to people; what we did not expect is this crazy level of support for it. 2k+ stars, 100+ companies and 400+ individuals pledged, and there is already more full-time engineering positions committed to it by pledging companies than the whole Terraform Core team at Hashicorp (source: terraform commit history)
An earlier version of the manifesto contained pledged resources from each company (you can still find it in commit history). It totalled to ~10 full-time engineers just from founding orgs. It was removed to simplify adding their entries for new pledgees