"For each ISO, we offer a checksum file with the corresponding SHA256 sum. For extra security, you can use GPG to verify who signed those .sha256 files. It should be 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284."
:) fair point..I'll let the YaST team know (or you could if you happen to be on freenode, they live in the #yast channel)
Users know - YaST doesn't change stuff without telling you, that was the point I was trying to make earlier. Users of YaST no longer have to worry about it silently taking over config files, it either co-exists or doesn't do anything without telling the user with great big pop-up boxes first
This enables 'osc install $foo' which will search the build service for package $foo and install it, which I believe to be the closest approximation of what you expect from AUR
It doesn't conflict with other configuration management systems. I've used openSUSE extensively with puppet and saltstack.
Many of SUSE's products use other configuration management systems as part of their toolchain, and SUSE are shipping SUSE Manager 3.0 with SaltStack, so their customers are expected to be able to use YaST alongside such a system
the only one I can think of is the apache one. If you use the YaST apache configuration module it will warn you before taking over and changing any local changes. It actually does its best to do a merge of local changes and its own, but it's the one case I know of where that merge can be destructive.
These days YaST no longer overwrites config files, except from a very few corner cases where it really really wants to be in control of specific config files for very specific reasons. But if it notices local changes, it warns the admin and doesn't take over unless the admin consents
So, no more unexpected config file obliteration :)
(and even if it did, YaST is integrated with openSUSE's default btrfs snapshot tooling, so YaST takes a snapshot before and after it changes anything, so you could always revert)
Yes, we share one test repo amongst all the openSUSE distributions and SUSE distributions
SUSE use openQA for testing their enterprise distributions too, and keeping all our tests together and reused as heavily as possible really helps in all directions (and proves the argument that maintaining openQA tests isnt hard even when dealing with multiple codebases-under-test all moving at different paces)
I use Tumbleweed as my daily driver on all my machines besides my server (Leap).
In 2 years I've had no problems that I didnt cause myself (eg. rm -rf /) and even then snapper saved the day and let me rollback to a working snapshot (Tumbleweed, like all openSUSE/SUSE distributions have btrfs snapshots and rollback by default)
So I'd say its comparible to Fedora or Debian testing
And we'd like to see more contributors, not only adding more packages and maintaining them, but to openQA also so that Tumbleweeds quality doesn't just stay at that level but gets even higher
Would love to be everywhere, so if any hosting companies want to get in touch about using openSUSE on their platform, my contact details are on the bottom of that article
Sure they can (and Fedora are already using and contributing to openQA)
But you really need to be using OBS too in order to produce those builds in the fast, easily contributed way that we then (ab)use with Tumbleweed
Of course, other projects could use OBS also..either hosting their own or by using our servers even..after all it builds Arch, Debian, Ubuntu, Fedora and other packages
But that's what being open is all about right?
Doing cool things because you need them and then benefiting even more when everyone else finally catches up and starts working with you on it :)
The search seems to be doing something weird at the moment..
There is a second "openSUSE Tumbleweed" under the "unsupported distributions" category, and that has the more up to date nvidia packages I'd expect
If someone would like to take a look at the lovely ruby behind software.opensuse.org and fix that bug, I'm sure we'd love the pull requests :) https://github.com/openSUSE/software-o-o
All you need if you're never going to update it or you're going to take steps to ensure the installed workload doesn't eat up excess space.