Pretty sure there has been various efforts to do this, but they all eventually stall due to being unable to keep up with the GIMP source. I hope this time they're taking an approach that will allow them to keep up with the maintenance.
What do you consider a power user? Because I'd consider an OS that refuses to let you do what you want, and constantly reverts your customisation, the opposite of power user friendly.
We're a long way not because Linux cannot do it. We're a long way because publishers refuse to take it serious.
Amazing tool, but I had to stop using it. On my Samsung phone, I gesture based navigation. And every time I use scrcpy, the navigation stops working, and I have to restart the phone to get it working again. There's a ticket open but the developer has been unable to replicate the issue. Sadly until that is fixed, it is impossible to continue using it. The inconvenience (at least for me) is too real.
Two things can be true at the same time. Yes, those meetings are horrible, and plenty of times they're useless and can be summarised as "why wasn't this an email/slack message", but also plenty of those same meetings can equally be extremely important.
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.
Yea, when you have multiple people doing anything, communication has to happen. It's not optional. As soon as your company hires developer #2, you need to communicate. As the team sizes get larger, 1:1 in-person conversations become less important and you need E-mail. As the team sizes get even larger and non-developer stakeholders become more numerous, meetings creep in. These things are not developer-torture devices. They are happening because your company decided that the product needs to be built by more than one person.
If y'all can find that company where the product is entirely developed soup-to-nuts by a single lone-wolf developer, without any other stakeholders or involved parties, by all means join that company! And tell HN about it--many of us would join it, too. But in the real world, development is a messy people-soup and you have to communicate.
> The author is rather vague about what exactly it asked it to do, he just says there was a “credentials mismatch” and Claude took the initiative to fix it by deleting the volume. But it’s likely that they are somewhat downplaying their culpability by being vague.
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.
Give an agent an obstacle and it will try to find a way around it. Most of the egregious commands Ive seen it run were fundamentally due to something blocking it from accomplishing a task. So eg if you block network access for the agent, you will get all sorts of creative solutions to try and get around the problem. This is also why its nearly impossible to corral commands. Because eventually it will rot13 encode a script and run it anyways.
I have had Claude go "oh, this query fails because the field I just added isn't in your sqlite database file, let me just delete it so it gets recreated". So I wouldn't rule out that Claude tries deleting a volume if it believes that will fix things and believes it isn't a production system.
That said, Claude seems to have gotten a lot more careful about these kinds of things in the last couple months
I'm not OP, but the whole podman compose topic gets quite confusing, as initially Podman didn't seem to know what they were trying to do. I've given some more context around it in previous comments.
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`.
One of the nastiest aspects of migrating from docker to podman really is "what to do about docker compose?" coz there are three wildly divergent ways to answer that all of which really suck under certain specific circumstances.
Im no fan of docker and podman by itself is a step up but orchestration headaches are enough to ruin that.
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.
* use systemd, red hat's favorite kitchen sink for handling everything from setting up sound services to mounting your home dir to logging so why not this too i guess.
* docker compose where i have to run a whole separate podman service to lie to docker compose about not actually being docker.
* podman compose which would be the obvious solution if it didnt just plain suck.
> * use systemd, red hat's favorite kitchen sink for handling everything
Systemd is a tool for managing services. Containers are services. Why require an entirely separate bespoke service manager when you're already running one?
> * docker compose where i have to run a whole separate podman service to lie to docker compose about not actually being docker.
This is the same system state as using docker compose with docker: you have a client program speaking to a backing daemon. Only difference here is the Podman service, being daemonless, only runs when needed (assuming you're setting up things the documented way by enabling the podman socket).
> * podman compose which would be the obvious solution if it didnt just plain suck.
Yeah I haven't had the best luck with it either. But part of the reason it's languished is that it makes more sense to just reimplement the Compose spec on the backend rather than re-invent the wheel and create a new compose client as well.
There's also the fourth option of writing Kubernetes yaml and applying that with `podman kube play`. Honestly this is probably closer to being the podman equivalent of docker compose but since it involves writing The Bad YAML (kubernetes) rather than The Good YAML (compose) most people don't use it.
It's a tool for user age verification that happens to be something you can use to manage services.
Did you miss my point about it being a filthy kitchen sink?
>This is the same system state as using docker compose with docker
One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point in the trash.
This shit is also incredibly fiddly. Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have.
Podman should stop trying to piggyback off docker if it's trying to be an alternative.
>Yeah I haven't had the best luck with it either. But part of the reason it's languished is that it makes more sense to just reimplement the Compose spec on the backend
Personally I suspect it languished because Red Hat simply cant abide the idea that somebody out there might avoid using systemd for something.
They happily built a docker compose to quadlets converter but they cant bring themselves to make podman compose not be a piece of shit even though it wouldnt be a lot of work.
> It's a tool for user age verification that happens to be something you can use to manage services.
Good talk buddy.
> Did you miss my point about it being a filthy kitchen sink?
I suspect there's not really a point in responding to this since you've already made up your mind.
Nevertheless, yes I am aware the systemd project contains many modular components. Some of which are good (systemd-the-service-manager that is what I was referring to), some of them are bad, and some of them are just odd (still haven't wrapped my head around systemd-homed's purpose). Podman integrates with the systemd service manager, not the rest of the project, so I'm really not concerned about that: there is no point where I am unable to use quadlets because I don't have, say `systemd-timesyncd` installed.
On the gripping hand, Quadlets are just a systemd-generator so there's nothing stopping you from getting that exact same benefits of Quadlets with some other service manager. You'd just have to write that implementation (and probably your own bespoke service manager) and will probably miss out on some of the niceties systemd provides to anything it manages.
> One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point in the trash.
You skipped the second part of my sentence where I reminded you that Podman is daemonless. There is no long-running Podman daemon/service/etc, it is spun up on demand and then stops when the action is done. Having a second process instance is not a daemon, and I'm not sure how you would have expected this to work otherwise.
> Ever had "docker compose" and "docker-compose" do subtly different things which drive your team mate to pull their hair out? I have.
..Take this up with docker?
> Personally I suspect it languished because Red Hat simply cant abide the idea that somebody out there might avoid using systemd for something.
> They happily built a docker compose to quadlets converter but they cant bring themselves to make podman compose not be a piece of shit even though it wouldnt be a lot of work.
I don't think `podman-compose` was ever an official Red Hat project. I don't think there was every really much interest in ironing out all the corner cases, especially before compose was actually fully specced, and once Podman itself implemented the spec the interest has been drying up.
Assuming you're referring to podlet[0] for the latter, that was never a Red Hat project.
>I suspect there's not really a point in responding to this since you've already made up your mind.
I suspect you ignored the point because you didnt want to address the point.
My repeating it seems to only have highlighted your wish to continue avoiding it here.
>Nevertheless, yes I am aware the systemd project contains many modular components.
Another red herring. "Modular" really isnt the point here.
It's certainly one way to justify throwing even more shit in an already overloaded kitchen sink though.
>You skipped the second part of my sentence where I reminded you that Podman is daemonless.
No, you skipped the part where I acknowledged that it was daemonless-by-default but you actually DO need to run a podman daemon if you're using docker compose with podman.
>Take this up with docker?
They're not responsible for podman trying to piggyback on their tools.
This is what stopped me from picking up Podman more, all our devs use Docker and have been writing compose files for years now. When the response at the time was "you're using Podman wrong, Quadlets are the hot stuff now" it just felt like too big a risk and commitment to jump to at the time. Have things settled more? Getting away from Docker is a bigger priority nowadays for us.
CPU cache space for code is much smaller than GPU memory for models (and the former is more important for performance since many CPU operations like pipeline parallelism are latency bound, not compute bound).
>This. Why spend extra on x3d cpu when you can have a reasonable game size (not that it has large enough cache anyway)
Because game(SW) devs/publishers don't care about spending money to optimize for reasonable size, and the enthusiast gamers want to play the game either way and will gladly fork out the cash for the HW to play it, if anything for the bragging rights.
Remember "will it run Crysis?" vintage 2007? Yeah, enthusiasts will be enthusiasts.
I'm a fan of the free market here. Badly optimized games will hurt their sales and force the studios to change or go bust, if the market decides so.
reply