Yes, you should use weed.
Why You Should Use Tumbleweed
41–50 of 68 posts
Re: Why You Should Use Tumbleweed
#42[deleted]
Re: Why You Should Use Tumbleweed
#43Ok, I'm a long time suse fan (ever since I dropped mandrake). But, mostly I run it in desktop VM's (openSuse) or on server class machines (sles). With the late 12.x series, it was working so well as a desktop OS in the VM that I decided to install it on a real piece of hardware and use it as a daily driver. That was a first for me in about 10 years. And it mostly worked on the laptop I installed it on. Wifi (including fn/enabled/disable buttons, and transitions between networks/wired/etc), suspend/resume, 3d acceleration/opengl, keyboard volume controls, etc all just worked. About the only thing that required futzing was the LCD brightness keyboard bindings were dorked (even though its a standard i3/etc machine) and the bluetooth was also broken. Three or four hours of recompiling modules, and messing with KDE/etc and everything on the machine worked. That made it the _ONLY_ laptop I've ever seen that worked without compromises in linux.
Fantastic experience, but with the 13.x series it seemed to go downhill a little. Enough that I stopped upgrading it because things break and I have to screw with it.
I wanted to like the leap concept, but it seems so many things were broken that the two days I spent trying to install it on a fairly normal x99 machine with a NVMe drive that I reverted it back to running it in a windows hosted VM.
I can't imagine what tumbleweed is like. Getting the kernel to boot and X to display graphics is just the first steps in my book. Plus, don't get me started on the UI changes. I want my desktop machine, and my servers to be _STABLE_. Screwing around with the bluetooth driver every time the kernel gets upgraded (or something similar) isn't something I want to be dealing with when I have actual work that needs finishing.
So, before someone tells me to try ubuntu/etc I'm going to say that I regularly run fedora/ubuntu/etc and they all have enough hangups that I continue to run opensuse based products at home (work has a different set of requirements, where I've been fedora/RHEL based recently rather than opensuse/sles).
Anyway, I really wish someone would take the leap type concept and stabilize the base OS/X/KDE and maintain it for a long time period while assuring that newer version of linux applications continue to work on that platform. You know, like windows (before 10). That way I won't have to worry that my 1 year old KDE version is to old to run a cd ripping application (or whatever).
Re: Why You Should Use Tumbleweed
#44Ok, I'm a long time suse fan (ever since I dropped mandrake). But, mostly I run it in desktop VM's (openSuse) or on server class machines (sles). With the late 12.x series, it was working so well as a desktop OS in the VM that I decided to install it on a real piece of hardware and use it as a daily driver. That was a first for me in about 10 years. And it mostly worked on the laptop I installed it on. Wifi (includin…
This is just anecdotal as well, but I've been running Tumbleweed for at least a year now on my Thinkpad. It's been rock solid. I'm a Gnome user though which I think makes a huge difference in this case, I see a lot of noise about problems with KDE.
Re: Why You Should Use Tumbleweed
#45Earlier quoted context omitted.
That doesn't sound very different from Debian Sid : new and updated packages are rolled in as they come through. This means fairly frequent breakages, especially for complex stacks. A lot of Debian-based distributions (including the first Ubuntu releases) are basically Sid snapshots at some point in time. It's been like that for a long time.
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.
Re: Why You Should Use Tumbleweed
#46I have some relatively fond memories of SuSE, because it was my first GNU/Linux distribution. Back then, it had the advantage of being pretty newbie-friendly (graphical installer / system control utility) and good ISDN support. Since ISDN apparently never became popular outside of Germany, not many distros had good support for it, and setting it up manually could be a real pain (at least for a newbie - a couple of years later, I set up a dial-on-demand ISDN router using NetBSD). So SuSE was, in retrospect a good choice for a first distro.
Eventually, though, I got fed up with YaST, because it used to overwrite config files and thus wipe out all manual changes one made to them. Does SuSE still do that? I remember reading about plans to rewrite YaST from scratch, so hopefully they found a better way of dealing with config files. From a UI perspective, YaST was a neat tool for non-techies.
Re: Why You Should Use Tumbleweed
#47Things that prevented me from using OpenSuSE: 1. no single letter user name allowed in the installer 2. yast rewriting config files 3. I couldn't get the partitioning tool to do what I tried which is plain simple /boot plus encrypted swap and root.
1. kinda true, though the current version of the installer lets you skip the username creation so you can do whatever you want afterwards :) 2. formerly true - YaST lives happily with config files these days. When possible it co-exists, only a few specific YaST modules need that absolute control and only rewrites them by warning you well in advance. ie. Not true any more 3. I think we fixed that..it's a radio button…
where can I find exact documentation about which config files are still manipulated / changed by yast and which are not?
Re: Why You Should Use Tumbleweed
#48I have some relatively fond memories of SuSE, because it was my first GNU/Linux distribution. Back then, it had the advantage of being pretty newbie-friendly (graphical installer / system control utility) and good ISDN support. Since ISDN apparently never became popular outside of Germany, not many distros had good support for it, and setting it up manually could be a real pain (at least for a newbie - a couple of ye…
YaST was written into Ruby, yes.
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)
Re: Why You Should Use Tumbleweed
#49Is this guy leaving out periods as some kind of intentional stylistic thing, or did he just fail at proofreading? Lots of other typos too. A little ironic when you're writing about doing things correctly and testing comprehensively!
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
Re: Why You Should Use Tumbleweed
#50Earlier quoted context omitted.
1. kinda true, though the current version of the installer lets you skip the username creation so you can do whatever you want afterwards :) 2. formerly true - YaST lives happily with config files these days. When possible it co-exists, only a few specific YaST modules need that absolute control and only rewrites them by warning you well in advance. ie. Not true any more 3. I think we fixed that..it's a radio button…
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.