196
Signal usage survey, what versions do you use? Wanted for potential Flatpak adoption
(community.signalusers.org)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Feb 2024
196 points (91.9% liked)
Linux
48740 readers
1211 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
I prefer the deb that works. I get a signal.update almost every other day. I don't remember to update my flatpaks anywhere near that often. I also appreciate that it doesn't force me to include dependencies that are already met.
You can update flatpaks automatically using systemd. Automatic updates are a thing and should be everywhere.
https://discuss.kde.org/t/improving-metered-network-detection-and-usage/9287
Absolutely not...most especially prior to production deployment. How else would someone see the change logs before hand or see/test if it would hurt their environment?
I have no idea what a production environment is for you. If it is some kind of sealed off stuff yeah maybe, but otherwise I hope you use a Distro that handles updates the way you need it.
Not updating because things will break is a sign of a bad distro.
Production environment is typically in the corporate world, not usually a homelab. Service providers often have a SLA uptime guarantee of 99%. They don't often push patches as soon as available due to the varied nature of corporate environment. They don't have one or two PCs to worry about: they can have tens of thousands. Downtime equates to money lost. So patches get tested before being deployed. Depending on the patch, that can be 48 hours to a week or two. Major OS upgrades can be months-long test, but the company usually does that and follows it while it's still in beta.
Updates are pointed to a server the company controls, not the Internet. Updates get tested on test servers and test machines that replicate those in production. It typically gets monitored for 48 hours to measure glitches and performance. Once satisfied, the company controlled update server pushes into production machines.
Why test patches before deploying to productions?
Ok this is a specific case, interesting info, thanks.
Obviously this has nothing to do with single user computers, going to software stores, pressing "update" buttons etc.
So it is unrelated to my point.