I'm inclined to agree. Jetbrains' own agent host 'Junie' was such a paim to set up and get working with other providers that I switched to Cline. I had moderately good results with using that as a coding agent, but eventually I switched to Deepseek Harness for generative tasks and am now using my IDEs more for review.
Legit answer, to be sure! But if already on macOS, how does it compare? “Better and cross platform!” is the best possibility. “Nearly as good, but free!” is also solid. “Eh, it’s fine if you don’t have access to Soulver”, wouldn’t be a ringing endorsement.
Let's just assume your claim is true, and it is impossible to build software in Europe.
European companies can still build software in different countries. Nothing stops them from building their software in an US subsidiary they fully control. A lot of good software developers are currently looking for a job.
Nobody is going to build any software in US when nearshore is 2-3 times cheaper. American engineers are overpriced and not competitive on the global market.
My claim is never about lack of brainpower in the EU. Clearly theres talent. Its a bit cultural, yes, but mostly its part of a framework that does not reward innovation. For a place with the best car manufacturing in the world and such a drive towards renewables, youd think Tesla should have come from EU. Or even should be replicated there. Why wont it?
Nobody wants “dirt cheap contractors who accomplish nothing” literally. That’s the figure of speech that has only one meaning in the context of conversation: that you supposedly think that outside of USA, people have lower qualifications. If you intended to say something different, feel free to elaborate.
I'm not sure if those comments are even bots. The bots seem to only amplify those opinions and make them more visible. It's a vicious circle, once those opinions are everywhere, more and more people pick up on them and write new posts like that.
> You can absolutely build images with a bash script, here's an example
That script is just calling docker to build layers manually via `docker create`/`docker commit`/`docker run`/etc, using a Dockerfile as a rudimentary DSL over it. It's still building images "the way docker does", but in a more error-prone way.
What GP is trying to say with "I would've been happy with a Bash script, or handing it a tarball", is that it ought to support giving it a literal tarball, like you'd get via `make install DESTDIR=./out && tar -czf image.tgz -C ./out .`. Or just tar'ing up the build artifacts of any other existing, competent build systems. There's no need to treat building an image as some "containerized" thing where you have to run inside the bottom layer of the container to build the artifacts.
In fact nowadays with the best practice of split container builds, there's no benefit of saying "the container is guaranteed to have the dependencies because it's the container you built with", because in practice nobody wants to ship their runtime containers with an entire build environment in them. So they do one container to do the building, then pick out the artifacts they need and place them in the runtime container. At that point, what's the point of using containers to build again?
And for most people, that's a bad idea. Most people don't have to know what RPATH, ldd, multiversion/simlink library discovery, etc are. And even if they did, Dockerfiles give you an easy way to do something you couldn't easily do before: multi-stage builds and a highly robust way to say "drop the parts of my transitive hull that were only relevant at build time". Dockerfile semantics kind of descend naturally from needing the behavior of stages, parallelization, cache keying for image layers, semantic layering (FROM), and making simple use-cases relatively at-a-glance/contained.
I never said you can’t do that, I’m merely pointing out that GP’s example isn’t an example of doing that.
My point is that the Dockerfile is not a particularly good build system. It doesn’t solve any of the hard parts (how to build the thing, what to build when) and only solves problems it created (how to avoid re-running something on every invocation) and does it poorly (it doesn’t track dependencies, just determines cached-not-cached on every line.) It leads to awful hacks like putting every build step on an enormous chain of `cmd && \` lines to make sure you don’t produce extraneous layers.
A reasonable build system tracks dependencies for what needs to be built and has a target it’s trying to get to. Docker just says “do your build imperatively and we’ll figure out caching” and it’s extremely easy to shoot yourself in the foot leading to overly large images.
An example: there’s no way to say “build container: do this build and put the product here, runtime container: take the product and store it here” without creating a temporary layer in the build container that is not used anywhere else. So if your artifact is 1GB, you will always require 2GB to do a build: one for the runtime container (where you want it) and one for the build container (where you only needed it temporarily.) You just have to do “docker builder prune” every now and then when your disk inevitably gets full, there’s no way to simply not produce the duplicate in the first place.
(My workaround is to keep the artifact in a type=cache mount, store its SHA sum in the build container, then in the runtime container, grab the artifact from the type=cache mount and compare the SHA sum to make sure it didn’t change. Cache mounts can be GC’d at any time so it’s not even guaranteed to work.)
When I used docker at scale back in the day, the thing that worked best was always: bind-mount an artifacts dir into the build container, run the build. Then package up the artifacts dir. Then at runtime, fetch the artifacts, bind mount them into the runtime container. Then you can use a real artifact store on a plain HTTP server instead of messing with docker layers (no more worrying about pushing 100 1KB layers because you didn’t put enough &&’s in your dockerfile) and it was so, so much faster than any docker registry was in practice.
Dockerfiles are great for simple stuff but, if I already have a great build system that produces single binaries, it’s so much more pleasant to just use that.
Edit: or is something stopping you from doing it this way? It seems like people just don't like Dockerfiles, but instead of just doing it differently (which is possible, it's just a tar file and a manifest), they keep complaining.
Good point. I get why some stacks use their own trust stores and not the system trust store. But there should be some mechanism to revoke trust to some of the CAs, without applying patches or rebuilding. Even if its just a convention based /etc/certs/revoked-certs file.
There were signs that others broke the embargo too. Public (this one video everyone is talking about), but maybe also non-public. There were some rumors going around which part of PHP was affected. That was enough for some people to figure out the vulnerability.
But it's also possible, that some attackers got non-public inside information.
If the embargo is already broken in a meaningful way, it suddenly becomes much less clear if it is still in place after all. Emphasis on >less clear<.
Sure, but what if there is disagreement? Or some people are unreachable? There wasn't any time to schedule a meeting, hear all arguments, think about it, meet again for a vote, ...
I'm still not saying that it was right to break the embargo first, but it's not as simple as it might seem.
An IDE still has it's uses, and it's perfectly fine without AI. Agents and IDEs have never felt like something that should be combined in my opinion.
reply