"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."
It probably didn't come across as well as I was hoping, but I wasn't going for a scathing-review motif. I could probably have couched my response a little more comfortably though. Kudos for the brave face and the positive reaction :)
Also, I didn't make the connection that you were the article author (!) - your followup on here has been admirable and impressive. Not many of the people who submit OC (of sorts) also follow up.
And thanks for writing this, it's definitely made me very curious about trying out OpenSuSE - or more accurately why I would try it. I'm using Arch at the moment, but I might be exploring in future :)
The AUR is pretty amazing, though... I don't use it that much, but it's nice that I've been able to install the stuff I have wanted with a single command. I get the impression there isn't a comparable alternative to this for SuSE...?
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
I noticed the 1-click install system, that's kinda cute :P (I have a vaguely similar experience when I go, er, Slackware package fishing.)
It seems to me that OpenSuSE (and SuSE itself) follows a philosophy of using centralized build management and verification, with a policy that supports minimal (if any) local from-source recompilation. Basically the exact opposite approach to Gentoo, the only distribution where gcc is more important than eth0 :P
This centralized model is actually exactly what I've been pining for for a very long time - an approach that a) verifies that XYZ works right in a central location, then distributes that known-working configuration, and b) creates an environment where clients are built using solely using such known-working configuration objects, and are thus relatively easily reproducible at scale.
I'm obviously testing OpenSuSE sometime in the short to medium term :D here's hoping it works out well for me in practice!
I'd heard of the OBS, but I didn't know the (Open)SuSE ecosystem was wrapped around it quite like I do now.
The one question I do have now is, where do you think OpenSuSE sits in relation to functional (ie static/absolute) package management? The distributed-known-working-blob approach sounds like it would fit in incredibly well with a model like what the Nix package manager uses.
Of course the current OpenSuSE ecosystem doesn't use this approach so adding it tomorrow would provide nothing unless everyone shifted mindsets, which would naturally not happen anytime soon. I'm just curious about what would happen if the two ideas were combined, since they don't seem to be particularly mutually exclusive or conflicting, and the result sounds like it might be potentially shiny and interesting (and possibly very powerful). And non-relative configuration sounds like the future (to me at least).
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)
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
Thank you for the UserVoice link, I added in my vote, hopefully others here in HN who enjoy SUSE do as well. I would also love to see SUSE more in the cloud, it is definitely a great distro.
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 :)
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.