Good on them for sticking it to Broadcom.
1,008 karma · joined July 10, 2023
Good on them for sticking it to Broadcom.
> - Docker support inside the container via a docker-in-docker sidecar (Please note: `--docker` uses `--privileged` under the hood (required for DinD), so it's not a sandbox against actively hostile code. Use it for repos you'd trust on your machine anyway.)
These statements are pretty contradictory. If dind has privileged access, then that means the agent has essentially root access (or access of the host user if rootless)
Yes I know you can run offline models, but it's hard to pass up on a little bit of snark.
If you had pointed out the original commenter's patronizing comment, as if they with 100% certainty know better than the author who has just written a book about said topic (at least the commenter thinks so), then I'd have agreed with you.
Sure, but we the only thing we know about the company is the current S1 filing. Need to time to see what all of that looks like. Fast tracking it and essentially forcing other people to buy without scrutinizing is the problem. They may very well be worth the money they claim, but we won't know until after they've proven it. That's what the rules are there for.
Also, S&P500 has a current market cap of $67 trillion, 0.3% of that is some $200billion. That is essentially a wealth transfer to the rich. They don't need it.
To answer your question, there have been plenty of business who have created and published free software (albeit plenty have later closed them). Notable examples are Databricks, Hashicorp, Mongodb, RedHat.
Sure they've built a moat on top of their free software, but they have (or had) free software regardless.
The world has literally become the people vs corporations. There is no soul in working any more.
We're a long way not because Linux cannot do it. We're a long way because publishers refuse to take it serious.
In fairness, given the context those meetings give, it stands to reason that giving that same context to an AI, it can, in theory, still do the same thing as an engineer. But those meetings still need to be had.
I don't understand what you're asking here. The answer to that is probably nothing. That is unless you want:
- systemd to manage your containers - You want to use K8s primitives (which are mostly compatible)
I'm unsure what the 3rd method is you're talking about. The nice thing about Podman's compose API is you don't have to change anything (mostly). You can point all your docker tooling to Podman's socket, and it'll (mostly) magically work.
I was just talking to my girlfriend saying I've realised that I've not written a single line of code, nor have I debugged myself for at least the past 3 months.
Having said that, given what I've seen Claude do, I find it hard to believe that Claude would go from credential mismatch to delete the volume. I understand LLMs are probabilistic, but going from "credentials wrong" to "delete volume" is highly unlikely.
> Supabase
I don't know enough about the Railway/Vercel/Replit, but I can tell you Supabase adds a huge amount of value. The fact that I don't have to code half of things that I otherwise would is great to start something. If it's too expensive, I can implement things later once there is revenue to cover devs or time.
You shouldn't be using podman compose. It's flimsy and doesn't work very well (at least it was last time I used it prior to Podman v3), and I'm pretty sure it doesn't have Red Hat's direct support.
Instead, activate Podman's Docker API compatibility socket, and simply set your `DOCKER_HOST` env var to that socket, and from there you can use your general docker client commands such as `docker`, `docker compose` and anything else that uses the Docker API. There are very few things that don't work with this, and the few things that don't are advanced setups.
For what it's worth, podman has also a thin wrapper (podman compose) which executes `docker-compose` or the old `podman-compose`. The docs should explain which it picks.
Note:
- `podman-compose` is an early attempt at remaking `docker-compose` v1 but for Podman. This used parsed the compose config and converts them to podman commands, and executes it.
- Later Podman wrote a Docker compatible socket instead, which can work with most docker clis that accept a `DOCKER_HOST` argument, including `docker` and `docker-compose` (both v1 and v2)
- `podman compose` is a thin wrapper that automatically selects `docker-compose` or `podman-compose` depending on which is installed.
Generally all you need is podman, docker-compose (the v2 binary), and that's it. From there you can use `podman` and/or `podman compose`.
Separately, how bad is it for future if I get a denial for any visa?
Linux and Git are fully open source, and have big companies contribute to it. If a company like Google, Microsoft etc need a feature, they can usually afford to hire someone and develop _and_ maintain this feature.
Something like gh is the opposite. It's maintained by a singular organisation, the team maintaining this has a finite resources. I don't think it's much to ask for understand what features are being used, what errors might come up, etc.
While I agree with you, sadly not everyone is in a position to just quit so easily, and even if the majority of the company quits, there are always people who are desperate enough to do the work and not complain.