I don't think so. I've also started small. There are entire operating systems like YunoHost who forgo containers. All the packages in Debian are laid out to work like that. It's really not an issue by any means.
And I'd say it's questionable whether the benefits if containers apply to your situation. If you for example have a reverse proxy and do authentication there, all people need to do is break that single container and they'll be granted access to all other containers behind that as well... If you mess up your database connection, it doesn't really matter if it runs in a container or a user account / namespace. The "hacker" will gain access to all the data stored there in both cases. I really think a lot of the complexity and places to mess up are a level higher, and not something you'd tackle with your container approach. You still need the background knowledge.
I don't want to talk you out of using containers. They do isolate stuff. And they're easy to use. There isn't really a downside. I just think your claim doesn't hold up, because it's too general, you just can't say it that way.
Well, hear me out… This is a self-hosted sub, I just run an *arr suite (lets face it, many here are), and do so in containers… They are not really distributed as packages AFAIK…
BTW my main nitpick of Debian is the outdated Podman packages… it wasn’t practical to run it there. Otherwise I too was content with Debian. I did mention this.
Sure. I think we could construe an argument for both sides here. You're looking for something stable and rock solid, which doesn't break your stuff. I'd argue Debian does exactly that. It has long release cycles and doesn't give you any big Podman update, so you don't have to deal with a major release update. That's kind of what you wanted. But at the same time you want the opposite of that, too. That's just not something Debian can do.
It's going to get better, though. With software that had been moving fast (like Podman?) you're going to experience that. But the major changes are going to slow down while the project matures, and we'll get Debian Trixie soon (which is already in hard freeze as of now) and that comes with Podman 5.4.2. It'll be less of an issue in the future. At least with that package.
Question remains: Are you going to handle updates of your containers and base system better than, or worse than Debian... If you don't handle security updates of the containers in a timely manner for all time to come, you might be off worse. If you keep at it, you'll experience some benefits.
I’ve always relied on Docker Hub and compose files (shared on the project page there), and never really delved deeper. It’s nice to hear recent Podman on the next release… So maybe it’ll become a viable option again.
I read that RHEL (and folks) is the standard, for Podman. But lately they have been riddled with licensing issues and big corporate nonsense, and found Alpine instead…
hendrik@palaver.p3x.de 1 day ago
I don't think so. I've also started small. There are entire operating systems like YunoHost who forgo containers. All the packages in Debian are laid out to work like that. It's really not an issue by any means.
And I'd say it's questionable whether the benefits if containers apply to your situation. If you for example have a reverse proxy and do authentication there, all people need to do is break that single container and they'll be granted access to all other containers behind that as well... If you mess up your database connection, it doesn't really matter if it runs in a container or a user account / namespace. The "hacker" will gain access to all the data stored there in both cases. I really think a lot of the complexity and places to mess up are a level higher, and not something you'd tackle with your container approach. You still need the background knowledge.
I don't want to talk you out of using containers. They do isolate stuff. And they're easy to use. There isn't really a downside. I just think your claim doesn't hold up, because it's too general, you just can't say it that way.
ntn888@lemmy.ml 1 day ago
Well, hear me out… This is a self-hosted sub, I just run an *arr suite (lets face it, many here are), and do so in containers… They are not really distributed as packages AFAIK…
BTW my main nitpick of Debian is the outdated Podman packages… it wasn’t practical to run it there. Otherwise I too was content with Debian. I did mention this.
hendrik@palaver.p3x.de 1 day ago
Sure. I think we could construe an argument for both sides here. You're looking for something stable and rock solid, which doesn't break your stuff. I'd argue Debian does exactly that. It has long release cycles and doesn't give you any big Podman update, so you don't have to deal with a major release update. That's kind of what you wanted. But at the same time you want the opposite of that, too. That's just not something Debian can do.
It's going to get better, though. With software that had been moving fast (like Podman?) you're going to experience that. But the major changes are going to slow down while the project matures, and we'll get Debian Trixie soon (which is already in hard freeze as of now) and that comes with Podman 5.4.2. It'll be less of an issue in the future. At least with that package.
Question remains: Are you going to handle updates of your containers and base system better than, or worse than Debian... If you don't handle security updates of the containers in a timely manner for all time to come, you might be off worse. If you keep at it, you'll experience some benefits.
ntn888@lemmy.ml 1 day ago
I’ve always relied on Docker Hub and compose files (shared on the project page there), and never really delved deeper. It’s nice to hear recent Podman on the next release… So maybe it’ll become a viable option again. I read that RHEL (and folks) is the standard, for Podman. But lately they have been riddled with licensing issues and big corporate nonsense, and found Alpine instead…
Shimitar@downonthestreet.eu 1 day ago
On gentoo, yes they are distributed as packages