It can indeed be uniform across ecosystems, but it's slow. There's a very serious difference between being on a team where CI takes ~1 minute to run, vs. being on a team where CI takes a half hour or even, gasp, longer. A large part of that is the testing story, sure, but when you're really trying to optimize CI times, then every second counts.

If the difference is <1 minute vs >30 minutes, containers (per se) are not the problem. If I was guessing blindly, it sounds like you're not caching/reusing layers, effectively throwing out a super easy way to cache intermediate artifacts and trashing performance for no good reason. And in fact, this is also a place where I think docker - when used correctly - is quite good, because if you (re)use layers sensibly it's trivial to get build caching without having to figure out a per-(language|build system|project) caching system.

You can have fast pipelines in containers - I’ve worked in quick containerised build environments and agonisingly slow non-containerised places, the difference is whether anyone actually cares and if there’s a culture of paying attention to this stuff.

Agree, and I would go another step to suggest dropping Docker altogether for building the final container image. It's quite sad that Docker requires root to run, and all the other rootless solutions seem to require overcomplicated setups. Rootless is important because, unless you're providing CI as a public service and you're really concerned about malicious attackers, you will get way, way, way more value out of semi-permanent CI workers that can maintain persistent local caches compared to the overhead of VM enforced isolation. You just need an easy way to wipe the caches remotely, and a best-effort at otherwise isolating CI builds.

A lot of teams should think long and hard about just taking build artifacts, throwing them into their expected places in a directory taking the place of chroot, generating a manifest JSON, and wrapping everything in a tar, which is indeed a container.

I mean personally I find nspawn to be a pretty simple way of doing rootless containers. Replace manifest JSON with a systemd service file and you've got a rootless container that can run on most linux systems without any non-systemd dependencies or strange configuration required. Dont even need to extract the tarball.

> reasonably large

Anyway you shouldn't have too many resources in a single Terraform workspace, for performance reasons. The real issues with Terraform come when you start to want to orchestrate different workspaces triggering each other, and trying to write that orchestration language, which itself would be declarative.

Terraform built a Stacks feature, but support is Terraform Cloud-only. OpenTofu has issues in the area that have been open for years: https://github.com/opentofu/opentofu/issues/931 https://github.com/opentofu/opentofu/issues/2860 and progress is slow, in part (IMO) because a genuine solution requires server-side evaluation (i.e. triggering applies as Kubernetes Jobs) and the open-source implementation of Terraform Enterprise/Cloud is a completely separate project with a completely different group of maintainers, Terrakube.

I'd argue the real issue with Terraform is that workspace orchestration is necessary in the first place. If they addressed the performance issues with large workspaces, then we wouldn't need to split up workspaces and Terraform could just orchestrate changes naturally.

The performance issues in large workspaces are due to needing to refresh status on all the resources in the large workspace before coming up with a plan. Actual apply time is either negligible or the inherently long amount of time it's supposed to take.

You split the workspace into smaller workspaces precisely to tell Terraform that you haven't made any changes to the networking layer, so don't bother trying to refresh the status of the networking layer to see if any changes are needed, it's not relevant when you're trying to scale up your Kubernetes cluster or whatever.

$30/committer/month, while only running scans biweekly, not even including "Enterprise" pricing, is really, really steep and will be a big barrier to adoption in larger enterprises with many engineers. You're basically asking enterprises to take the $30/committer/month pricing that they're spending on something like GitLab Premium, and double it, for bug reports? They may be great bug reports, but if it's difficult enough to get teams to merge automated MRs from tools like Dependabot/Renovate, what makes you so confident that a large enterprise customer will be so willing to add Another Tool that opens More MRs that require engineers to spend More Time Reviewing that may or may not have anything to do with shipping more features out the door?

Please consider a pricing model that's closer to bug bounties. There's clearly a working pricing model where companies are willing to pay bounties for discovered vulnerabilities. Your tool finds vulnerabilities (among other classes of bugs). Why not a pricing model where customers agree up-front to pay per bug your model finds? There are definitely some tricky parts to that model - you need an automated way of grading/scoring the bugs you find, since critical-severity bugs will be worth more (and be more interesting to customers) compared to low-severity bugs, and some customers will surely appeal some of the automatic scores - but could you make it work? Customers could then have more control over scaling up usage of Detail (adding slowly to more repositories), including capping how many bugs of each severity they would like reports for (to limit their spend), allowing customers to slowly add more repositories and run scans more frequently to find more bugs as they get more proven value from the tool.

We've been thinking about this too. We have some ideas. Thanks for the comment, in any case – gave us a lot to chew on.

> But then your various managers have the ammunition to decide what to do next - allocate more resources to the project, descope the project, push back the release date, etc.

In your view, is this a good thing or a bad thing for developers? In other words, are developers incentivized to update their tickets because it gives their managers "ammunition" to make project changes?

I find that this is usually more evidence of organizational dysfunction.

Sometimes, its developers who don't have enough ownership - someone higher-ranking filled out all the tickets for them and left no room for interpretation, so changes require trashing a bunch of irrelevant tickets and writing a bunch of new ones, making for more communication overhead and less time spent in development. Developers are disincentivized to update tickets since doing so just becomes write-amplification for more bureaucratic overhead.

Sometimes, it's a communication breakdown. Tools like Jira are necessarily asynchronous, and decisions about what to build are necessarily political. Politics and asynchronicity don't mix, such discussions need to be held face-to-face. If they're held face-to-face, then having developers update Jira is pure overhead. Developers are disincentivized from updating Jira because either it's a one-sided conversation (lag in getting notified that your ticket was closed and the work on it should be thrown out, PMs don't always follow through with issue links from the closed issue to the newly opened issues, so developers lack context on what decisions were made on replacements), which is emotionally draining, or the conversation happens outside of Jira, in which case updating the ticket is a formality/not actual communication, in which case it feels like a waste of time.

For most development work, I'd argue that developers shouldn't be making changes in Jira, their managers should be, on the basis of frequent, synchronous communication with the developers they manage.

> someone needs to be getting less for doing more, so that someone else doing less can have more

This is true of all societies, not just socialist ones. In capitalism, it's called philanthropy and charity. The underlying social contract is noblesse oblige, that the right to enjoy the trappings of wealth comes with an obligation to ensure that the poor are reasonably taken care of.

The real difference that socialism poses is not that it should happen at all, but that it should happen by force with the power of the State, due to the wealthy as a class no longer making the independent free choice of discharging such obligations.

Having needs is not the same as slavery. Wage slavery is described as such because of the power imbalance between employer and worker, who has limited agency to find another employer, with whom he would also have a relationship with a power imbalance.

A wealthy man who receives a check for dividends and interest most months is not subject to such power imbalances. Wealth makes him free.

It's not an argument that socialism would enable people to just live off a public dividend, so to speak. Somebody has to work, and workplaces require discipline. Rather it's an argument for better labor safety controls, and a personal appeal to people to save as much money as they can.

I've been an employer. I didn't have any power over my employees. If there was anything they didn't like, they simply stopped coming to work. How was I supposed to make them show up?

One embezzled a large amount of money and spent it on drugs. What was I supposed to do about that? He was broke, he couldn't pay the money back. All I could do was tell him to not come back.

I've also been employed at minimum wage jobs, and salaried jobs. I never felt the employer had power over me. At my salaried jobs, my coworkers complained about all the power the company had over them. The company had no power over me, so I would ask them what the power was. After some long conversations, the problem was the coworkers spent every dime of their income. So not having a paycheck for a week was a catastrophe. The company, however, was unaware of these issues.

I recommend saving up to 6 months of living expenses, and then the employer will have no leverage over you.

A lot of people forget that going hungry is the default state of not doing a thing. The super rich and socially progressive societies redistribute the taxes they levy on the productive people to help the people who can not (elderly, ill) or won't (lazy bastards) work. It might be a better deal for the society as a whole, to offset the cirme that would ensue if there isn't any social net.

A lion in the plains of Africa is not entitled to a dinner, the farmer in not entitled to a crop yield. It is super rare that people can't do anything to better themselves and get more for their own skills or execution. Any buisness owner will gladly share a percentage of profit you generate for them if you can show them you're indeed generating such profit.

If you're in DPRK or Cuba then you'd need to check your free-market priviledge of having a market for your skills.

> to offset the cirme that would ensue if there isn't any social net.

The recent news from Minnesota suggests that the social safety net is a magnet for astonishing levels of theft.

It's not the social safety, but the bad enforcement of the law. When bad acts are not punished, this is the problem that occurs.

Some social systems like in Israel if you're ablebodied you are given a public service job, like cleaning the park and etc... so you aren't entitled to a check for doing nothing.

South Africa hasn't any meaningful social net and the wealthy people live in special "high security" enclaves with additional guards and fenced perimeters. If you have a lot of hungry people on the street they will be forced to survive somehow and you'd get more crime.

This is part of the false dichotomy you are not understanding. It's not actually a valid choice if there are no options. And that is what this is actually about, understanding how we have no good options, and what to do about it. I recommend start digging in and we all question or own understanding and acceptance of the system. Is it actually working with even a simple majority in the best position we can be?

Currently employing 130 wage slaves and unduly profiting from their margins, and not satisfied with the overall system at all.

If you are a US citizen in the US, you have options. There's absolutely nothing an employer can do to force them to stay.

I understand your point that a typical US citizen has options where they work.

My point is when all options include wage slavery it's not an actual option. That's it, a false dichotomy.

And that is what the OP is about. It's exploring a fundamentally different system which I understand is scary.

Please tell me about "wage slavery" in the US with US citizens and why they have no options.

Asking this question leads me to suspect you have no true curiosity or willingness to learn a new perspective as it's literally a Google away. And then you will reply in another direction that justifies your narrow world view that is of course justified 100% by your experience. This is not effective discourse and I see you doing it all over.

It’s a well-documented economic concept. You can find plenty on it if you're actually curious about the perspective. And understanding it thoroughly is a strong prerequisite to seriously engaging with other people with intent to learn. It's work you need do yourself.

It would have taken less effort to answer the question than what you did write.

Brendan Gregg deserves respect. Intel? Their reputation had been in the gutter for a few years now. The classic way to offend a nerd is to have a leading market position, tons of cash and resources, then squander it on politics and bullshit.

> I had one developer openly tell me, "I don't want to learn anything new."

To play Devil's Advocate here, there's a big, big difference between JavaScript-ecosystem-style framework/library/fad-of-the-month where you are nagged on a daily basis that your libraries and tools are out of date, to building everything in Go on the back of the standard library, deploying to some LTS distribution.

The benefits of technical stability for product agility are real. Yes, it may mean your codebase is in a subset of C++ and is the domain of a 50+-year-old, genuinely-Senior Engineer who's been writing C++ for more than thirty years, who you will need to sit and negotiate with to make product changes. C'est la vie. Calling that tech debt, in and of itself from the outside, is not really fair, that's ageist.

There are precisely two people who can determine whether or not there is technical debt: (a) the lead IC responsible for the codebase, according to their innate understanding of the state of the codebase, (b) the manager who is responsible for the IC who both (1) observes that release agility is at risk and (2) is willing to invest in non-functional work to get future increases to release agility.

This was the takeaway I had taking to a colleague about his time at Intel - they're a genuinely global company with engineering teams in practically all time zones who are still expected to collaborate with each other. No matter what time of day the meeting was scheduled for, it was the middle of the night for somebody, and no, just working on written docs async for everything didn't cut it, and they couldn't just fly people out all the time. So that's apparently just part of what it means to take a job at Intel these days.