I doubt bundling things together in some sort of pack would avoid every problem with python versions I could have. That doesn’t prevent a given python version from being marked as “end-of-life” and no longer receiving security patches.
Most software is produced and maintained for use solely by the company that produced it, and probably by people who are not experts in using python, so hiding the complexity that python versions and dependency versions are coupled seems like a bad idea, especially when one wants to limit the number of versions of the same software that is installed (and therefore re-use executable files to save disk and CPU usage and avoid accidentally using the wrong version of a program).
I have not interacted with flatpak in a professional environment, so I doubt I have been directly harmed by it. However, reducing the importance of quickly upgrading software after new versions are released is probably harmful overall: performing an upgrade will usually make development easier (so making it harder for me to pitch to managers that an upgrade should be done is harmful to my morale), and incentivizing having multiple versions of the same program accessible on the same system makes surprising problems more likely.
I think they’re talking about that time PopOS messed up Steam packaging and it was broken and it just so happens Linus (the tech tip guy) was trying to install it then and he ended up running a command to rememedy the situation that totally broke his shit. It was pretty funny
Linux: I can’t install steam without breaking my system
Steam Deck: am I a joke to you?
Yes.
laughs in flatpak
Unpopular opinion: flatpaks enable lazy developers to keep old versions of required Python dependencies working longer.
And that is bad?
Yes.
deleted by creator
Yes. Lack of clarity on what python version to use causes me pain on a regular basis.
If only there was a way to bundle it all together, like in some sort of pack…
I doubt bundling things together in some sort of pack would avoid every problem with python versions I could have. That doesn’t prevent a given python version from being marked as “end-of-life” and no longer receiving security patches.
Most software is produced and maintained for use solely by the company that produced it, and probably by people who are not experts in using python, so hiding the complexity that python versions and dependency versions are coupled seems like a bad idea, especially when one wants to limit the number of versions of the same software that is installed (and therefore re-use executable files to save disk and CPU usage and avoid accidentally using the wrong version of a program).
I have not interacted with
flatpakin a professional environment, so I doubt I have been directly harmed by it. However, reducing the importance of quickly upgrading software after new versions are released is probably harmful overall: performing an upgrade will usually make development easier (so making it harder for me to pitch to managers that an upgrade should be done is harmful to my morale), and incentivizing having multiple versions of the same program accessible on the same system makes surprising problems more likely.I think it’s fine as long as they aren’t terrible insecure. But if they’re using an old runtime, people will bother them about it.
Maybe you and Linus can’t…
https://lemmy.world/post/1188262
deleted by creator
I think they’re talking about that time PopOS messed up Steam packaging and it was broken and it just so happens Linus (the tech tip guy) was trying to install it then and he ended up running a command to rememedy the situation that totally broke his shit. It was pretty funny
laughs in Wine