Live data from Hacker News

Why You Should Use Tumbleweed

rootco.de

51–60 of 68 posts

Re: Why You Should Use Tumbleweed

#51
post #40

Earlier quoted context omitted.

You've unfortunately been massively downvoted for saying this, but I think you're right. Also, in Tested Well just before the screenshot I couldn't understand the sentence "And if we don’t test it well enough we want to and you can contribute tests as everything in [openQA is 100% open source]." The author mentions at the bottom that it was inspired by a Reddit article, so I think this was just thrown together in rap…

Will do..thanks for the critique

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...?

Re: Why You Should Use Tumbleweed

#52

Earlier quoted context omitted.

Apart from Debian Sid: has no testing, but Tumbleweed does - so those breakages don't happen

Most (if not all) packages installed in any *nix have tests, which (hopefully) are run during the system-specific package creation.

Testing packages, and testing that an entire distribution works with those packages on it, are two very different things..

Re: Why You Should Use Tumbleweed

#53

Earlier quoted context omitted.

where can I find exact documentation about which config files are still manipulated / changed by yast and which are not?

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.

Thank you very much for your attention - however I asked where I can find exact documentation about these things?

"Mr Brown from Suse wrote in a HN thread..." will not be enough as a reliable source of information. Yes, I could just read the source, however I am expecting such an extraordinary important thing that will change my config files to be documented. I need precise information here.

Also it would be important to know how this conflicts with configuration management systems like chef, ansible, puppet etc. - or is yast able to manage multiple workstations itself, so is is a replacement for these tools?

Thanks!

Re: Why You Should Use Tumbleweed

#54

Earlier quoted context omitted.

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.

Thank you very much for your attention - however I asked where I can find exact documentation about these things? "Mr Brown from Suse wrote in a HN thread..." will not be enough as a reliable source of information. Yes, I could just read the source, however I am expecting such an extraordinary important thing that will change my config files to be documented. I need precise information here. Also it would be importan…

There is pretty extensive documentation on http://yast.github.io/documentation.html

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

Re: Why You Should Use Tumbleweed

#55
post #51

Earlier quoted context omitted.

Will do..thanks for the critique

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 fo…

There is the graphical option, using http://software.opensuse.org and the 1-click install functionality there to add packages direct from OBS

on the commandline, there is a plugin for osc (the OBS commandline tool) https://build.opensuse.org/package/show/openSUSE:Tools/osc-p...

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

Re: Why You Should Use Tumbleweed

#56

Earlier quoted context omitted.

Thank you very much for your attention - however I asked where I can find exact documentation about these things? "Mr Brown from Suse wrote in a HN thread..." will not be enough as a reliable source of information. Yes, I could just read the source, however I am expecting such an extraordinary important thing that will change my config files to be documented. I need precise information here. Also it would be importan…

There is pretty extensive documentation on http://yast.github.io/documentation.html 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 alongsid…

Multiple 404 on that page:

http://www.rubydoc.info/github/yast/yast-yast2/

http://yast-core.readthedocs.org/en/latest/

I am not trying to make you angry, but I think I put the finger right on the place where it hurts very much.

There is no clear documentation about what yast does or what it will not do - basically a blackbox. Maybe it will change apache config. Maybe not. Who knows.

Re: Why You Should Use Tumbleweed

#57
post #51

Earlier quoted context omitted.

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 fo…

There is the graphical option, using http://software.opensuse.org and the 1-click install functionality there to add packages direct from OBS on the commandline, there is a plugin for osc (the OBS commandline tool) https://build.opensuse.org/package/show/openSUSE:Tools/osc-p... This enables 'osc install $foo' which will search the build service for package $foo and install it, which I believe to be the closest approx…

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).

Re: Why You Should Use Tumbleweed

#58
The main problem these days is that people don't give a fuck about packaging their software for the constellations of distributions that exist. OpenSUSE topic-repositories usually offer the latest packaged version of most things for the Stable version too (say the Games repository), where available. But in many cases, latest versions are just not there for anyone.

We are in a model now where OS repositories have been replaced by npm, pip, rubygems in the best case. By pulling from Github's master branch in the worst (wink at Golang). In a sense, your system is already a rolling distro, except plugged to a third-party-managed repository which you trust to install packages produced by total strangers.

Re: Why You Should Use Tumbleweed

#59

Earlier quoted context omitted.

There is pretty extensive documentation on http://yast.github.io/documentation.html 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 alongsid…

Multiple 404 on that page: http://www.rubydoc.info/github/yast/yast-yast2/ http://yast-core.readthedocs.org/en/latest/ I am not trying to make you angry, but I think I put the finger right on the place where it hurts very much. There is no clear documentation about what yast does or what it will not do - basically a blackbox. Maybe it will change apache config. Maybe not. Who knows.

:) 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

Re: Why You Should Use Tumbleweed

#60
post #39
post #22

This does all sound quite compelling. Somehow OpenSUSE has fallen under my radar, I've been an Arch user for a few years, and Gentoo user before that, and I'd only ever be interested in rolling distros, but I wasn't aware that OpenSUSE had Tumbleweed for this. I did find dependency conflicts all too common on Gentoo, and keeping the system up to date was a frequent struggle. I've not had any major issues with Arch re…

I agree with you on Gentoo. I loved the project from the rolling distribution standpoint and had run it for a while but long-term maintenance of it was a mess. I'd reserve a few hours for doing updates since every emerge would have me validating via diffs every configuration file (which it, unintelligently, wanted to return to the "sample" state). Tumbleweed struck the right balance for me. Bleeding edge, rolling dis…

Being a Gentoo user for years, if your issue is the config file updates I would say they are nearly if not the same, AFAIK there are some better tools other than etc-update that may make it easier.

The whole compiling from source well you can avoid some that with binary packages but that is not the focus of the distro, it has always been compiling from source.

About the updates I currently run it on a server and plan on moving my laptop from windows to Gentoo, at least on the server there are no issues, I have a cron to run sync everyday and send me an email report, when where are too much new packages I update it, usually pretty quick, unless there are new versions for gcc or other large packages (gcc takes 15min). I would say give it a try again.

Post reply on HN