On Mon, Oct 19, 2015 at 3:47 PM, Richard Brown wrote:

On 19 October 2015 at 15:01, jcsl wrote:

...

Hi.

Currently we have repositories with the latest versions of desktops and some applications (KDE, GNOME, Mozilla, ...) Will they be available for Leap too?

Greetings.

Hi,

I do not want to speak for the individual maintainers for those individual repositories -

Whether or not they want to make repositories for that purpose is a decision for them to make. I'm about to express below my opinion, but ultimately, it's up to our maintainers, and they're fully within their right to ignore everything I say now.. but personally speaking, if I was in their shoes, I would _not_ bother with 'latest version' repos for Leap.

We have Tumbleweed for the 'latest of everything' use case. It's a LOT easier for us to maintain a fully rolling release, than trying to keep a constantly moving software stack (GNOME, KDE, Mozilla) working ontop of a static base.

Most of the time, when something goes wrong, it's often easily fixed by updating to the latest things from upstream or updating something somewhere else in the stack to fix the integration issues.

And if it's easier for us to maintain (and test - Tumbleweed has openQA, something which none of those projects currently do) it's less likely to break for our users..

Lots of work has gone into Leap to make it a STABLE distribution. It's taken us months to put it together and make it work right. A lot of that work has been integrating the chosen versions of all those software stacks so it can act as a stable, curated, consistent, operating system, which should serve everyone who downloads it well until at least 42.2 comes out a year from now.

Such stuff doesn't happen overnight, has required lots of work and lots of testing from lots of different angles. No addon repository is going to have that level of scrutiny and effort.

Furthermore, taking individual software stacks, and piling them ontop of a static base, is a lot more work for our maintainers to do, and it doesn't take much for people to be able to make very horrific combinations that would just never work. Just look at the 'old Tumbleweed' model (Tumbleweed from before Nov 2014) - that was our old regular releases, with an addon repository with a selection of new packages (GNOME, KDE, Mozilla, Kernel) maintained and curated by a renowned kernel developer, but even then it broke a lot, because it's frankly harder to build something that works, and stays working, that way.

More integration points, more ways stuff can go wrong, especially when still trying to do it at a pace that follows the upstream projects, but that unmoving base makes it harder to find solutions to make it right.

So, my hope would be that we start moving away from that model.

While addon repos have indeed been dodgy regarding stability, they have been very valuable, so your assessment seems quite nearsighted. Yes, it's difficult to make them hold to the same standards as stable distributions. But unlike rolling distributions, you don't have to risk your whole system (and time) to update some component you absolutely need. Furthermore, you won't know you need the addon repo until after you installed and have been working with the distribution for a while. Say you install Leap, and it's fine because at that point everything's the latest or close enough. Let a year pass, and while you got all the security updates, you start noticing that this annoying little bug in software X just became a showstopper for you, and see that a newer version has it fixed. Software X is a leaf package, so you think: I should just update it, but yeah, it depends on libY and libZ. Still, nothing else uses libY, and the libZ update is binarily backwards compatible, so you update, and live happily ever after. Sure, it's tricky, you can actually break things. But the nature of the breakage is far more limited and predictable than in the case of tumbleweed's "zypper dup", which simply by following the mailing list can be scary to watch if you actually depend on your computer for your livelihood. Add to that the fact that people will simply wash their hands if you use TW and don't dup (updating a single package? you're on your own), and you can start to appreciate the value of addon repos. So, I agree, addon repos for core components (say Mesa) would probably be too much effort to be worth it. But that's not something you can or should generalize. Leaf packages should be just fine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Oct 19, 2015 at 4:38 PM, Richard Brown wrote:

On 19 October 2015 at 21:14, Claudio Freire wrote:

...

While addon repos have indeed been dodgy regarding stability, they have been very valuable, so your assessment seems quite nearsighted.

Yes, it's difficult to make them hold to the same standards as stable distributions. But unlike rolling distributions, you don't have to risk your whole system (and time) to update some component you absolutely need.

I'd argue my opinion isn't nearsighted, I'm speaking from the school of experience.

I've seen it both as a user and as a maintainer. I've done the 'rolling stuff ontop of a stable base' as a user of old-Tumbleweed I've been part of the team that built repos for that scenario with GNOME:Stable repos (which I also used)

I would put gnome in the same bucket as Mesa, though. So your experience, I'd say, is heavily biased towards the "not worth the effort" portion of packages.

...

Furthermore, you won't know you need the addon repo until after you installed and have been working with the distribution for a while.

Say you install Leap, and it's fine because at that point everything's the latest or close enough. Let a year pass, and while you got all the security updates, you start noticing that this annoying little bug in software X just became a showstopper for you, and see that a newer version has it fixed. Software X is a leaf package, so you think: I should just update it, but yeah, it depends on libY and libZ. Still, nothing else uses libY, and the libZ update is binarily backwards compatible, so you update, and live happily ever after.

Sure, it's tricky, you can actually break things. But the nature of the breakage is far more limited and predictable than in the case of tumbleweed's "zypper dup", which simply by following the mailing list can be scary to watch if you actually depend on your computer for your livelihood.

Add to that the fact that people will simply wash their hands if you use TW and don't dup (updating a single package? you're on your own), and you can start to appreciate the value of addon repos.

So, I agree, addon repos for core components (say Mesa) would probably be too much effort to be worth it. But that's not something you can or should generalize. Leaf packages should be just fine.

I love this example, because it actually feeds into something that I expect to see with Leap's future development

Lets imagine this situation, where something with Leap 42.1 is a little on the rough side, and could be fixed by updating the package

In 1 years time (possibly a little earlier) Leap 42.2 will be out. In this scenario, that update that you want of a leaf package, shouldn't be thrown in some random repo, but be submitted as part of 42.2.

This theoretical example is a perfect example of the kind of thing the 'minor versions' of Leap are intended to address, but in that case, the minor versions will be tested, polished, tested again, integrated, and polished some more as one consistent upgrade for 42.1

Leap should be something people can put their faith into, the development model we have for Leap ensures that, while the lifecycle we have for Leap means that we'll have annual opportunities to take care of issues just like the one you raise above.

The Frankenstein monsters created by throwing together random collections of disjointed repositories are never going to measure up against Leap or even Tumbleweed when it comes to reliability or dependability.

So why expend the additional effort? Lets focus on the core problems, getting our two main distros, Leap and Tumbleweed, as good as they can be, for the use cases they exist to address :)

Lets hope the transition from 42.1 to 42.2 holds to your expectations. If it does, I'll probably turn to your side. For now, in my experience, the one from 13.1 to 13.2 didn't, because of the same reason I already pointed out: such a wholesale update updates more packages than you need. If everything's silk-smooth, that's great. But things rarely are silk-smooth. OpenQA only does basic testing, you'll have to recognize, some things depend on people testing, and some use cases get none of that. Maybe addon repos are only for knowledgeable users, since I happen to be one of those, and I prefer a small, known set of potential problems (up 1 package), to an unknown, potentially large set of problems (dup). It does hinge on me being able to predict that first, small set of potential problems, so it does require knowledge. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Oct 19, 2015 at 5:31 PM, Richard Brown wrote:

On 19 October 2015 at 22:02, Claudio Freire wrote:

...

On Mon, Oct 19, 2015 at 4:38 PM, Richard Brown wrote:

...

On 19 October 2015 at 21:14, Claudio Freire wrote:

...

While addon repos have indeed been dodgy regarding stability, they have been very valuable, so your assessment seems quite nearsighted.

Yes, it's difficult to make them hold to the same standards as stable distributions. But unlike rolling distributions, you don't have to risk your whole system (and time) to update some component you absolutely need.

I'd argue my opinion isn't nearsighted, I'm speaking from the school of experience.

I've seen it both as a user and as a maintainer. I've done the 'rolling stuff ontop of a stable base' as a user of old-Tumbleweed I've been part of the team that built repos for that scenario with GNOME:Stable repos (which I also used)

I would put gnome in the same bucket as Mesa, though. So your experience, I'd say, is heavily biased towards the "not worth the effort" portion of packages.

Okay, but then, if you're defining it as the 'very end of the tree' leaf packages..lets say, stuff like LibreOffice?

Well, Libreoffice in *SLE 12* is moving from 4.whatever it ships to 5.0 in a *maintenance* update soon.. which is why it's been so easy for us to throw it into Leap so late ;)

And I dont know what Wolfgang has planned for Firefox, but I guess the point is, we already have a policy of allowing packages at that 'end of the branch' to be updated as part of the regular maintenance of our distributions, both in former releases of openSUSE, also in SLE, and so I suppose no reason to think we won't also do it in Leap.

So, if your limiting your scope to just those sort of packages, you just need to persuade the maintainers to push the changes as maintenance updates..which should be easy to do, its less work for them than building and maintaining whole new repos at least ;)

In that sense I guess you're right, but maintainers haven't been doing that. Perhaps, as you say, they should just do that.

...

OpenQA only does basic testing, you'll have to recognize, some things depend on people testing, and some use cases get none of that.

openQA does pretty damn advanced testing, and I challenge you to find something which openQA absolutely cannot test. Multi machine, multipath, HA, real hardware, you name it, openQA can do it, or we want to find a way to make it do it.

The biggest limitation is not the technology, but that someone has to care enough about an issue to write a test for it

That's not that hard to do - https://github.com/os-autoinst/openQA/blob/master/docs/WritingTests.asciidoc

And there is lots of examples to learn from - https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/tests

Even when there's the technical possibility of testing, it's not always done. See what's happening with i586. You really think if someone wrote a few thousand tests covering every workflow for the top 90% of users, it'd actually be run? There would probably not be enough resources to do that amount of testing. And nobody did write that many tests. And no, it's not that easy. I read OpenQA test scripts and they read like chinese to me, and I consider myself quite capable of reading code in any language. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2015-10-19 22:59, Richard Brown wrote:

...

See what's happening with i586.

Wasting hardware testing hundreds of scenarios on an architecture a minority, a shrinking minority

Taking position as devil's advocate - one might as well ask why we test XFCE/LXDE. It's a "minority", after all. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Monday 2015-10-19 22:59, Richard Brown wrote:

...

...

See what's happening with i586.

Wasting hardware testing hundreds of scenarios on an architecture a minority, a shrinking minority

Taking position as devil's advocate - one might as well ask why we test XFCE/LXDE.

Because the GNOME and KDE monsters suck so much.

It's a "minority", after all.

If you're going to drop XFCE as well it seems I have to look out for another distribution. Ciao, Michael.

Yeah, it's the needles that confuse me really.

I may give it another try, if I find something worth testing that isn't being tested already.

Well when writing a new test, you end up coding tests with needles with tags that don't exist yet Then you run those tests, until they fail, and take the screenshots and define the needles using the webUI, then assign the correct tags to those needles In an ideal world an awesome openQA test writer might do all of that on their own machine and then send a pull request for both the code and the needles Occasionally we're quick and dirty and just write the test code, test it on our own machines, then throw the test code in a PR and handle the needles fresh in production when the test is run for the first time.. ;) Not good practice, but in your case, if you did write a new test 'blind' without any needles, once it passed review I'd happily give some time to a google hangout or so to give you a 10-20 minute explanation on how to use the Needle editor in openQA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 19 October 2015 at 23:03, Greg Freemyer wrote:

On Mon, Oct 19, 2015 at 4:49 PM, Claudio Freire wrote:

...

...

So, if your limiting your scope to just those sort of packages, you just need to persuade the maintainers to push the changes as maintenance updates..which should be easy to do, its less work for them than building and maintaining whole new repos at least ;)

In that sense I guess you're right, but maintainers haven't been doing that.

Perhaps, as you say, they should just do that.

Last I knew, an update could only be pushed if there was an open bugzilla it was addressing.

That is one reason I know I haven't pushed routine updates via the update channel.

Please clarify what the desired maintainer behavior is when a new leaf package release is available, but there are no reported bugs against the old release.

I think your understanding of the situation is correct, our maintenance workflow requires bugs to be reported - but if there are no bug reported, then Claudios example doesn't fit ;) Or to put it another, plain english way Package Updates to fix reported bugs - OK for Leap Package Updates 'just because its newer' - Tumbleweed With those two (existing) options, I still don't see the need for additional repos :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2015-10-19 at 17:03 -0400, Greg Freemyer wrote:

On Mon, Oct 19, 2015 at 4:49 PM, Claudio Freire wrote:

...

...

So, if your limiting your scope to just those sort of packages, you just need to persuade the maintainers to push the changes as maintenance updates..which should be easy to do, its less work for them than building and maintaining whole new repos at least ;)

In that sense I guess you're right, but maintainers haven't been doing that.

Perhaps, as you say, they should just do that.

Last I knew, an update could only be pushed if there was an open bugzilla it was addressing.

That is one reason I know I haven't pushed routine updates via the update channel.

Please clarify what the desired maintainer behavior is when a new leaf package release is available, but there are no reported bugs against the old release.

Yes, it needs a bug, but don't make your life miserable for that. GNOME for example has been pushing out dot releases on 13.2 twice IIRC... both times we just open a bug, like bugzilla.suse.com/show_bug.cgi?id=938799 It's merely informative that what will be updated (planning work) and helps the maintenance team to report issues seen against an existing bug... no black magic needed in there. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Oct 20, 2015 at 7:44 AM, Stefan Seyfried wrote:

On 19.10.2015 23:03, Greg Freemyer wrote:

...

Last I knew, an update could only be pushed if there was an open bugzilla it was addressing.

Greg, just ping me if you need a bug opened against any of your packages so that you have a reason for pushing an update :-P

Or just file yourself a bug report

Stefan, When there is an actual meaningful bug addressed by the new release I have certainly done that. Otherwise, I have followed the philosophy of openSUSE to not update packages in a stable release just because one is available. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Oct 20, 2015 at 2:35 PM, Steven Hess wrote:

Nvidia works fine here with open source driver. I can play Minecraft full screen and get motion sick. So saying Nvida doesn't work is wrong. It doesn't work for some corner cases. It works fine for many people. Quit spreading disinformation.

GPU-demanding applications aren't corner cases. Saying so *is* disinformation. And no, it's not just games. Blender also needs good GPU performance. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Oct 19 22:31 Richard Brown wrote (excerpt):

... defining it as the 'very end of the tree' leaf packages ... So, if your limiting your scope to just those sort of packages, you just need to persuade the maintainers to push the changes as maintenance updates

An example where a version upgrade makes sense but a maintenance update does not make sense: Pure printer driver packages are such kind of 'very end of the tree' leaf packages. "Pure printer driver package" means that the package contains only a plain (CUPS-compliant) printer driver without additional fancy stuff like GUI-tools and so on. Therefore HPLIP (HP's software for printers and all-in-ones) is not a "pure printer driver" - in contrast those packages are pure printer drivers: - gutenprint - epson-inkjet-printer-escpr For printer driver packages a version upgrade makes sense only for those users who actually have a printer device that is not yet supported with the version that we have in Leap (which is what we have in SLE12). Because printer driver packages support very many different printer models it is less than hopeless to have them tested by us in a reasonable way which means: Basically printer driver packages are not at all tested for all the different supported printer models. Therefore a printer driver package version upgrade as maintenance update is not possible because regressions for this or that printer model are unknown in advance. Or in other words: When a printer driver package version works for a particular user with a particular printer model there is zero reason to enforce a version upgrade for that user by a general maintenance update. On the other hand when a printer driver package version does not work for a particular user with a particular printer model there is zero reason not to do a version upgrade and try out if the newer version may work for that particular model (provided the newer version claims that model is supported). Therefore what I do to provide the newest versions to users who may need them is that I build them in the OBS "Printing" project for as many openSUSE and SLE versions as possible with reasonable effort, cf: https://build.opensuse.org/project/show/Printing FYI: gutenprint-5.2.10 in Leap and SLE12 provides PPD files for 2341 printer models. gutenprint-5.2.10pre11.2 (second pre-release of the upcoming Gutenprint 5.2.11) in OBS "Printing" provides PPD files for 2617 printer models, i.e. there are 276 more printer models available. epson-inkjet-printer-escpr-1.4.0 in Leap and SLE12 provides PPD files for 386 printer models. epson-inkjet-printer-escpr-1.5.0 in OBS "Printing" provides PPD files for 448 printer models, i.e. there are 62 more printer models available. Those more available printer models are mainly newer printer models that are nowadays or recently purchasable so that a newer printer driver package version could be primarily of interest for users who buy new printers. In contrast users who have or buy PostScript printers or PCL5e monochrome laser printers do not need printer driver packages, cf. "Printer drivers: Make the printer print" in https://en.opensuse.org/Concepts_printing Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Oct 19, 2015 at 3:38 PM, Richard Brown wrote:

Lets imagine this situation, where something with Leap 42.1 is a little on the rough side, and could be fixed by updating the package

In 1 years time (possibly a little earlier) Leap 42.2 will be out. In this scenario, that update that you want of a leaf package, shouldn't be thrown in some random repo, but be submitted as part of 42.2.

It may be too early to ask, but what happens once 42.1 is released (next month?) Is something like 42.2-factory going to be created so packages destined for 42.2 can start to be accumulated? Or do we wait for the next SLE 12 Service Pack and have an entire redo of the 42.1 dev process? Just curious. Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 19 October 2015 at 22:08, Greg Freemyer wrote:

On Mon, Oct 19, 2015 at 3:38 PM, Richard Brown wrote:

...

Lets imagine this situation, where something with Leap 42.1 is a little on the rough side, and could be fixed by updating the package

In 1 years time (possibly a little earlier) Leap 42.2 will be out. In this scenario, that update that you want of a leaf package, shouldn't be thrown in some random repo, but be submitted as part of 42.2.

It may be too early to ask, but what happens once 42.1 is released (next month?)

Is something like 42.2-factory going to be created so packages destined for 42.2 can start to be accumulated?

Or do we wait for the next SLE 12 Service Pack and have an entire redo of the 42.1 dev process?

Just curious.

Greg

Too early to say for sure For starters, we don't know when SUSE are planning SLE 12 SP2, and that will be something we want to factor into our decisions regarding the timeline for Leap 42.2 Those discussions have only just started internally at SUSE, though I do not expect them to take a very long time. What SUSE plan to include in SLE 12 SP2 will also need to be considered when it comes to deciding what we put in to Leap 42.2 - for example if SUSE are planning on putting in a new kernel (something which I know they are considering), that might make a decision about what we do about the Leap kernel a lot easier than figuring that all out on our own :) But, I assume as soon as we know enough to get started, we'll come up with a timeline of sorts, and a development process which broadly follows how we've put together Leap 42.1, just with tunings and refinements from the lessons learned from 42.1...and then changing things on the fly in response to whatever lessons we learn on the way to 42.2.. no one ever said we had to have this all figured out before we start building it..if we did, we'd never build anything ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

nHi. El Lunes, 19 de octubre de 2015 23:57:00 Richard Brown escribió:

On 19 October 2015 at 23:31, jcsl wrote:

...

Hi.

When I made my question I had in mind users that can't use Tumbleweed because they have/want to use proprietary drivers (video drivers for the most part) but still want to be up to date. They're those under the "Who should use the normal stable release?" section on Portal:Tumbleweed.

In fact, in this precise moment I'm using 13.2 + kernel:stable + XOrg without any problem at all

Um, you're interested in this topic because Tumbleweed doesn't recommend using proprietary drivers....And then you're running 13.2 with a non-default kernel and xorg?

You didn't understand me right. My 13.2 installation is like this because I was going to install Tumbleweed anyway so I don't really care if it breaks or not... but the fact is that it has been working without issues. It also was to express my opinion on that having extra repositories doesn't necessarily mean an unstable system. As I said, I've been using the updated KDE repository since the beginning and my experience has been fully positive. I currently use KDE and LXDE (which I help packaging) so I don't know how does it works on other desktops. I'm not interested in the topic for me (I removed my NVIDIA card and I'm using the on board AMD/ATI with the radeon driver) but for the users that want to have recent applications and use the proprietary driver because a) they want to (gaming or whatever) or b) they have to due severe problems with the free drivers. It's no unusual at all to read comments of users coming back to the stable release because they have problems with the free video driver and they don't know how to install the blob (even though it's all explained in the wiki, sad but true). And if they do install the blob they still can have problems now and then if they don't lock the kernel and perhaps Mesa.

The _exact_ reason Tumbleweed doesn't recommend using proprietary drivers is because changing the kernel and Xorg are _precisely_ the things that breaks the proprietary drivers most often

Sure..sometimes it works, and theres always someone somewhere who can make it work, but the advice for Tumbleweed exists as good practice for those who don't want to have to deal with such risks

Meanwhile, your 13.2 + kernel:stable + XOrg carries probably more risk than Tumbleweed does it's just as likely to break the Prop. drivers, and because more people use Tumbleweed than your custom combination of stuff, it's going to be faster/easier to fix any issues on Tumbleweed, where as you're on your own with your own custom repos...

Of course, I wouldn't recommend such a mix of repositories. I was just and example of the, in my opinion, great work that openSUSE packagers do. Even with such a bleeding edge config the system still runs like a charm. :) Don't get me wrong, I won't complain it the extra repositories disappear. Mine is an innocent question to know what will happen because it will be of help for me to choose between Leap or Tumbleweed. :D

This example kind of illustrates exactly why I'd like to see a de-emphasis on additional repos...

Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 20 of October 2015 13:33:18 Graham P Davis wrote:

On Mon, 19 Oct 2015 23:57:00 +0200 Richard Brown wrote:

...

The _exact_ reason Tumbleweed doesn't recommend using proprietary drivers is because changing the kernel and Xorg are _precisely_ the things that breaks the proprietary drivers most often

On TW, Plasma5 doesn't work with the default driver (nouveau); it only works with the proprietary nVidia driver so not recommending the use of proprietary drivers means not recommending the use of Plasma5.

...or not using an NVidia GPU. :-) Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Howard Guo [10-20-15 09:15]:

Hello.

It is misleading to say that Nvidia proprietary driver does not work well on Tumbleweed. I've never had any trouble with it.

This morning I edited the Tumbleweed portal and NVIDIA-the-hard-way pages to get rid of the misleading information.

Kind Regards, Howard

On Tue, 20 Oct 2015, Michal Kubecek wrote:

...

On Tuesday 20 of October 2015 13:33:18 Graham P Davis wrote:

...

On Mon, 19 Oct 2015 23:57:00 +0200 Richard Brown wrote:

...

The _exact_ reason Tumbleweed doesn't recommend using proprietary drivers is because changing the kernel and Xorg are _precisely_ the things that breaks the proprietary drivers most often

On TW, Plasma5 doesn't work with the default driver (nouveau); it only works with the proprietary nVidia driver so not recommending the use of proprietary drivers means not recommending the use of Plasma5.

...or not using an NVidia GPU. :-)

Michal Kubeček --

And I have been using nVidia proprietary drivers forever, only experiencing problems when kernel changes required changes to the driver install package. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op dinsdag 20 oktober 2015 15:58:47 schreef Carlos E. R.:

On 2015-10-20 15:01, Michal Kubecek wrote:

...

...or not using an NVidia GPU. :-)

And what would you use, for high performance video? I like Intel, but it is not up to the task. The two contenders I know both have proprietary blobs.

-- Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith))

To watch video, an Intel does the job fine, you don't need an NVIDIA or AMD. Gaming IMHO would be valid. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 20/10/2015 18:17, Patrick Shanahan wrote:

But working 500 raw photographs does require the nvidia prop driver! nouveau just cannot keep up.

Why? :-? Displaying static photos should not be a problem, and processing is done by the CPU, not the video hardware. The card and driver should not matter, as long as they are capable of displaying with proper resolution and number of colours. -- Saludos/Cheers, Carlos E.R. (Minas-Morgul - W10) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Carlos E. R. [10-20-15 18:50]:

On 20/10/2015 18:17, Patrick Shanahan wrote:

...

But working 500 raw photographs does require the nvidia prop driver! nouveau just cannot keep up.

Why? :-?

Displaying static photos should not be a problem, and processing is done by the CPU, not the video hardware. The card and driver should not matter, as long as they are capable of displaying with proper resolution and number of colours.

OpenCL support provides 3-4 x performance. And memory in the video hardware is utilized, so it does matter. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 21 Oct 2015 02:09, Carlos E. R. wrote:

On 21/10/2015 1:14, Patrick Shanahan wrote:

...

* Carlos E. R. <> [10-20-15 18:50]:

...

On 20/10/2015 18:17, Patrick Shanahan wrote:

...

But working 500 raw photographs does require the nvidia prop driver! nouveau just cannot keep up.

Why? :-?

Displaying static photos should not be a problem, and processing is done by the CPU, not the video hardware. The card and driver should not matter, as long as they are capable of displaying with proper resolution and number of colours.

OpenCL support provides 3-4 x performance. And memory in the video hardware is utilized, so it does matter.

But I still don't understand. Increase performance, how, in what? It's a static image, stored compressed as some kind of bitmap in a file. You only need to convert to a standard bitmap, which is done by the cpu in addressable memory, then display it. Then, it is idle.

What do you need display speed for? :-?

I'm displaying raw photos in this laptop which only has an Intel video. I notice no issues at all. Possibly they even display faster tonight, that I'm using Windows :-p

Carlos, Carlos, .... Think about a (semi-)professional photographer that does things like: recalibrating colors (redshift, blueshift, ...) recalibrating dynamic range (16bit/12bit/10bit to 8bit rgb) mounting multiple singlurars to panoramas, with correcting angles, etc All this implies MASSIVE amounts of computations done. for a single RAW, die difference between 60 seconds CPU and 35 seconds GPU+CPU worktime is not the world. Now, multiply by 500, for a full workday load. How many hours do you want to work per day, to have the money you need? 500*1min = 8h20min, 500*35sec = 4h51min. Reality bites. Hard. A soup-dish as perspective will not give the whole picture. Until Intel takes the executives heads out of the behinds of their superiors, and get performance into their GPUs (-- have you seen the joke that is Skylake Graphics for desktops??) third party discreete GPUs are needed. Sadly that implies drivers from the same company, as FOSS drivers do not bring features os performance or are missing even both. So long OpenCL and cohorts will not work with the FOSS drivers, using them is a pipe dream for many that use Linux for their work. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Carlos E. R. [10-20-15 22:00]: [...]

Ah. You mean using both the GPU and CPU for running _code_, for which not only you need the proprietary driver, but also other drivers, plus specific applications that are able to offload processing into the GPU.

Ah, yes :). "Working" the key word, not merely displaying but cropping, adjusting angle, light, dark faces, color correction, and then producing jpg's for web display.

You could have just said what you were doing. Displaying a hundred raw photos is not the issue, it is something entirely different.

No, it was never about "displaying" but making displayable product.

Having a 128 core CPU and working in parallel would also help, way more than a single GPU, I guess ;-)

Well, 12 core and 36 gig memory is a start :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Oct 21, 2015 at 2:26 AM, Michal Kubecek wrote:

On Wednesday 21 of October 2015 02:37:45 Yamaban wrote:

...

Think about a (semi-)professional photographer that does things like: recalibrating colors (redshift, blueshift, ...) recalibrating dynamic range (16bit/12bit/10bit to 8bit rgb) mounting multiple singlurars to panoramas, with correcting angles, etc

All this implies MASSIVE amounts of computations done. for a single RAW, die difference between 60 seconds CPU and 35 seconds GPU+CPU worktime is not the world. Now, multiply by 500, for a full workday load.

I wonder what CPU you have that it takes so long. Processing a raw from Canon 7D (18 Mp) took ~8 seconds on my old 2x2GHz Athlon64 CPU and is even faster now with FX-4350 (4x3.8 GHz). As the steps I need to do for "almost no postprocessing" pictures take me way longer than that, I see no need for GPU offloading.

Stitching or HDR tone mapping is quite compute-intensive, especially on High-Res pictures. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 20 of October 2015 15:58:47 Carlos E. R. wrote:

And what would you use, for high performance video? I like Intel, but it is not up to the task. The two contenders I know both have proprietary blobs.

Not sure what exactly is "high performance video" supposed to mean. For my purpose, radeon driver serves perfectly fine with both 2560x1440 at home and 2x1920x1080 at work. Haven't tried 4K yet as those available at reasonable price today are all unreasonably small so that there would be little use (for me) in buying one. Of course, I'm not a gamer. If I was, I would probably need Windows for games anyway and then the question of open/close source drivers would be irrelevant. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 2015-10-21 at 15:18 +0200, Carlos E. R. wrote:

  One simple 3D game for Linux, open source and using 3D, is "tuxracer". From its description:

ermm.. tuxracer... I doubt this makes use of ANY modern technology... especially considering that this has not been updated in > 10 years.

+++----------------- extreme-tuxracer - Open source racing game featuring Tux the Linux Penguin

Extreme Tux Racer is an open source racing game featuring Tux the Linux Penguin. ETRacer continues in the tracks of Tux Racer and its forks. -----------------++-

It is a very simple game, but it demands quite a bit from the graphics engine.

yes, it did.. 10 years ago.. nowadays, any phone has more CPU power than this game could ever consume Maybe better try supertuxkart: it's built around modern 3D engines :) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op woensdag 21 oktober 2015 15:39:41 schreef Carlos E. R.:

On 2015-10-21 15:28, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2015-10-21 at 15:18 +0200, Carlos E. R. wrote:

...

One simple 3D game for Linux, open source and using 3D, is "tuxracer".

...

From its description: ermm.. tuxracer... I doubt this makes use of ANY modern technology... especially considering that this has not been updated in > 10 years.

Well, extreme-tuxracer is a port of the older tuxracer. Seems to be from 2011, but at sourceforge I see activity this summer.

Yep, that will have been sourceforge implementing their windows advertising mechanism :D.

As I said, I'm not a gamer ;-)

...

...

It is a very simple game, but it demands quite a bit from the graphics engine.

yes, it did.. 10 years ago.. nowadays, any phone has more CPU power than this game could ever consume

LOL. Not my phone - running a GPS task crashes it :-p

...

Maybe better try supertuxkart: it's built around modern 3D engines :)

I just installed it, to have a look ;-)

-- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op woensdag 21 oktober 2015 15:18:19 schreef Carlos E. R.:

On 2015-10-21 07:35, Michal Kubecek wrote:

...

On Tuesday 20 of October 2015 15:58:47 Carlos E. R. wrote:

...

And what would you use, for high performance video? I like Intel, but it is not up to the task. The two contenders I know both have proprietary blobs.

Not sure what exactly is "high performance video" supposed to mean. For my purpose, radeon driver serves perfectly fine with both 2560x1440 at home and 2x1920x1080 at work. Haven't tried 4K yet as those available at reasonable price today are all unreasonably small so that there would be little use (for me) in buying one.

AMD also has proprietary drivers.

...

Of course, I'm not a gamer. If I was, I would probably need Windows for games anyway and then the question of open/close source drivers would be irrelevant.

I'm not a gamer either, but now and then I like to try something to play, for relaxation. And games that use 3D rendering have problems without proprietary drivers. Currently I don't have Windows games, and there are, I think, two companies selling big games for Linux.

One simple 3D game for Linux, open source and using 3D, is "tuxracer". From its description:

+++----------------- extreme-tuxracer - Open source racing game featuring Tux the Linux Penguin

Extreme Tux Racer is an open source racing game featuring Tux the Linux Penguin. ETRacer continues in the tracks of Tux Racer and its forks. -----------------++-

It is a very simple game, but it demands quite a bit from the graphics engine.

There are other non gaming, graphic intensive applications, but as I don't use them I'd better not try to say which. blender?

Hey, not very long ago (2 yrs?) gnome refused to run without proper acceleration.

-- Cheers / Saludos,

Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Re. tuxracer/ETracer: When was this line on the demands writen? There's no such thing as a 3D engine ( like in modern games ) in it. AFAIK it's over 10 years old, so I doubt it uses GPUs the way modern games do. Blender is a good example AFAICT. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2015-10-21 15:18, Carlos E. R. wrote:

+++----------------- extreme-tuxracer - Open source racing game featuring Tux the Linux Penguin

Extreme Tux Racer is an open source racing game featuring Tux the Linux Penguin. ETRacer continues in the tracks of Tux Racer and its forks. - -----------------++-

It is a very simple game, but it demands quite a bit from the graphics engine.

How do you figure? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-21 20:48, Michal Kubecek wrote:

On Wed, Oct 21, 2015 at 03:18:19PM +0200, Carlos E. R. wrote:

Anyway, this started with a claim that Plasma 5 doesn't work (well?) with noveau and a response that it means "either not using Plasma 5 or not using Tumbleweed". I have no idea if the claim true - all I wanted to say was that even if it is, the response is not true as with an AMD GPU - even with a low-end one like Radeon5450 - and the open source radeon driver, there is absolutely no problem to run Plasma 5. This is my personal experience: I'm using Tumbleweed with Plasma 5 and radeon driver on one of my machines.

Understood. The generic recommendation, and written on our wiki, was not to use Tumbleweed if you required the proprietary drivers, because the rpm can not be provided, and driver integration can break often. Of course, there are (many?) people doing it without problems. But there are also (many?) users who would not know what to do if graphics mode one day does not work after an update, so the recommendation is just generic. A precaution, to be on the safe side. On the other hand, there are desktop applications, even the entire desktop, that require or can use hardware graphic acceleration. If it is not available, they may drop down features, or even fail to work - this is what the gnome desktop did (LibreOffice also, sometimes I remember some posts). It is possible, I understand, that with some card models the open source driver works well enough so that you don't even notice. But there are cards that are not that well supported by the open driver. The contrary is also true: some old cards are no longer supported by the proprietary driver. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYn7RgACgkQja8UbcUWM1yfugD/ZmqroICiL7BNth4nOdwKWgSf IiwBG6BR3NPZpHqnVukA/RNFkk4QAF37RChowTiCHOBxnCeiy7vdmd582epgrHlp =/lmE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org