openSUSE released Slowroll variant, the slower version of Tumbleweed, which sounds really perfect for a MicroOS on servers and even PCs.
openSUSE doesn't say directly, but that is what openSUSE ALP (MicroOS + Slowroll) would looks like.
Now, since it just released I won't use it anyhow, but once it gets more love from openSUSE and its community I will switch my Tumbleweed MicroOS installs on Slowroll.
https://en.opensuse.org/openSUSE:Slowroll
openSUSE doesn't say directly, but that is what openSUSE ALP (MicroOS + Slowroll) would looks like.
Now, since it just released I won't use it anyhow, but once it gets more love from openSUSE and its community I will switch my Tumbleweed MicroOS installs on Slowroll.
https://en.opensuse.org/openSUSE:Slowroll
There's questions about why do I use openSUSE.
I have some principles to the OS that will be on servers and should be reliable.
First, it should be maintained by the more or less big company that earns money maintaining the OS it makes. Examples: Canonical, SUSE, Red Hat, etc.
The distros maintained by very small teams like Linux Mint, Alpine Linux and PopOS are just unsafe to use.
Next, the OS should exists for more than 10 years to be proven as a reliable and enterprise solution.
One of the most important ones is OS reliability itself. The package managers usually comes with some kind of reliability insurance, such as Transactions, Snapshots, Logging, etc. Some of distros has better package managers, some of them has awful ones.
I would highlight Debian's DPKG + APT, which has nothing really to prevent itself from going to the third state (a state when package managing failed and you have inbetween state), those are complicated to resolve in Debian and everybody I asked had experience dealing with it.
Now, I would prefer having immutable OS, so it couldn't be destroyed anyhow by doing package management or running scripts.
The examples of such OSes are: openSUSE MicroOS, Fedora Silverblue, Fedora Core
The biggest advantage of such OSes is that auto updates are generally very secure, since they can't break your system, both Fedora and MicroOS can automatically restore the last working snapshot if they find that update failed.
By my expirience the most suitable OS from my rules and the most stable OS is openSUSE MicroOS.
I have some principles to the OS that will be on servers and should be reliable.
First, it should be maintained by the more or less big company that earns money maintaining the OS it makes. Examples: Canonical, SUSE, Red Hat, etc.
The distros maintained by very small teams like Linux Mint, Alpine Linux and PopOS are just unsafe to use.
Next, the OS should exists for more than 10 years to be proven as a reliable and enterprise solution.
One of the most important ones is OS reliability itself. The package managers usually comes with some kind of reliability insurance, such as Transactions, Snapshots, Logging, etc. Some of distros has better package managers, some of them has awful ones.
I would highlight Debian's DPKG + APT, which has nothing really to prevent itself from going to the third state (a state when package managing failed and you have inbetween state), those are complicated to resolve in Debian and everybody I asked had experience dealing with it.
Now, I would prefer having immutable OS, so it couldn't be destroyed anyhow by doing package management or running scripts.
The examples of such OSes are: openSUSE MicroOS, Fedora Silverblue, Fedora Core
The biggest advantage of such OSes is that auto updates are generally very secure, since they can't break your system, both Fedora and MicroOS can automatically restore the last working snapshot if they find that update failed.
By my expirience the most suitable OS from my rules and the most stable OS is openSUSE MicroOS.
it has now assigned another CVE ID, CVE-2023-5129, marking it as a critical issue in libwebp with a maximum 10/10 severity rating. This change has significant implications for other projects using the libwebp open-source library.
Now officially recognized as a libwebp flaw, it involves a heap buffer overflow in WebP, impacting Google Chrome versions preceding 116.0.5845.187.
Now officially recognized as a libwebp flaw, it involves a heap buffer overflow in WebP, impacting Google Chrome versions preceding 116.0.5845.187.
Forwarded from Ackyl Дристаяр
This media is not supported in your browser
VIEW IN TELEGRAM
Idk what to reply so
Google patched Pixels in its September update against the vulnerability, which is tracked as CVE-2023-4211
Forwarded from Marshal ✨ via @tt_video_dwnld_bot
This media is not supported in your browser
VIEW IN TELEGRAM
👍2
https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2023-2539
Samsung with its Knox and security modules in kernel be like
Samsung with its Knox and security modules in kernel be like