[opensuse-factory] Will we have additional repositories for Leap as we have currently?
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. -- 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 15:01, jcsl
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. If you want the latest of everything, use Tumbleweed, where the entire Tumbleweed community works together to make sure the resulting distribution is integrated, consistent, tested, and working If you want something more stable and that changes less, use Leap If you want something in between..well, good luck, but the chances are that you're going to end up creating a monster that will bite you sooner or later, and it's going to be pretty hard for anyone to help you in that case.. -- 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:47 PM, Richard Brown
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 19 October 2015 at 21:14, Claudio Freire
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) and in both cases, despite my best efforts, neither got anywhere NEAR the level of quality and reliability that Tumbleweed is at, today, and every day as for the risk - with openQA protecting me before the point of distribution, I've never experienced breakage like I did with pre 2014 Tumbleweed or even with openSUSE+GNOME:Stable. And even with that in mind, with snapper + btrfs + grub2 boot from snapshot ALWAYS giving me a 'get out of jail free' option on my own machines, there really is no risk. Why put extra effort into creating additional repos for latest software on Leap when we already have the _best_ option for that use case in Tumbleweed? 'It just works', it's been 'just working' for me for over a year now, and if there is ever a moment that it doesn't, I can roll the whole thing back to the last time that 'it just worked' and then know that I have a very strong, fast, reliable community who will help me get the issue fixed bloody quickly, and then implement tests to make sure it never happens again. (NOTE: The only time I've needed to use btrfs snapshots in the last 14 months on running Tumbleweed on all of my machines was due to user error where I accidentally tried to delete the majority of the contents of my root partition. So we have unequivocal proof that I'm more dangerous to my own machine than any of the updates we've rolled out to Tumbleweed in the last 14 months)
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 :) -- 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
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 19 October 2015 at 22:02, Claudio Freire
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 ;)
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
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.
Maybe, but I'm trying to talk from wisdom and experience here, not knowledge I can agree with you that addon repos SHOULD be a viable option. But I can also very clearly state that I've seen that tried for enough years to strongly advocate for alternatives, because just because they SHOULD work, doesn't mean they ever have and I haven't seen any reason to believe that they COULD work better now.. -- 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
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
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.
Wasting hardware testing hundreds of scenarios on an architecture a minority, a shrinking minority, of users use isn't an effective use of hardware..sure But we still are going to keep an i586 'canary' or two around to keep some attention on that old platform. If people would like to donate more testing hardware, they can contact donations@opensuse.org, we'll gladly take it and integrate it into the openQA system.
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.
We're running a few hundred different scenarios, each including 20-30 tests, so yes, we're already at the few thousand test mark..
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.
https://openqa.opensuse.org/tests/94150/modules/gedit/steps/1/src Really? it's not that hard..starting at line 10 I'll decode into plain english (the rest is boilerplate stuff, as described in the docs) 10 - load the X11 application called gedit 11 - check the screen is showing gedit launched 12 - type the string "If you can see this text gedit is working.\n" 13 - wait 2 seconds 14 - check the screen is showing the text 15 - wait 2 seconds 16 - press alt-f4 17 - wait 2 seconds 18 - press alt-w 19 - sleep 2 seconds Even the most complicated tests all share a common heritage with simple ones like this example..just as we want to delve a little deeper, things sometimes get a little bit more fanciful..but that's the same with all programming :) -- 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
On 19 October 2015 at 23:46, Jan Engelhardt
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.
We currently (and have always) test XFCE/LXDE at precisely the same level we're now testing i586.. one or two scenarios (each containing ~35 tests) to make sure it's still working okay This compares to previously, where Tumbleweed i586 testing was dozens of different scenarios, each containing 20-40 tests, effectively duplicating the effort we were already doing on x86_64 It was nice for completeness, but not proportionate and very wasteful of time and hardware.. XFCE/LXDE is actually a good example of how i586 is now getting tested more proportionally to similarly popular stacks/platforms, thanks! -- 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.
On Mon, Oct 19, 2015 at 5:59 PM, Richard Brown
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.
Wasting hardware testing hundreds of scenarios on an architecture a minority, a shrinking minority, of users use isn't an effective use of hardware..sure
I agree, that's why I say OpenQA can only do limited (I said basic, but I should have used "limited") testing. The cost-benefit balance stops being positive after some point.
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.
We're running a few hundred different scenarios, each including 20-30 tests, so yes, we're already at the few thousand test mark..
And it's already at its limits, which is, as I understand, why i586 tests are being nixed.
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.
https://openqa.opensuse.org/tests/94150/modules/gedit/steps/1/src
Really? it's not that hard..starting at line 10 I'll decode into plain english (the rest is boilerplate stuff, as described in the docs)
10 - load the X11 application called gedit 11 - check the screen is showing gedit launched 12 - type the string "If you can see this text gedit is working.\n" 13 - wait 2 seconds 14 - check the screen is showing the text 15 - wait 2 seconds 16 - press alt-f4 17 - wait 2 seconds 18 - press alt-w 19 - sleep 2 seconds
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 Mon, Oct 19, 2015 at 4:49 PM, Claudio Freire
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. Thanks 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 23:03, Greg Freemyer
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 10/19/2015 05:08 PM, Richard Brown wrote:
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 :)
Because not every one thinks that two sizes fit all use cases. Anyway, the hole discussion is somewhat pointless. Those maintainers that want to provide newer packages for Leap can do so by simply adding Leap as a build target. Those that don't simply will not. There are plenty of packages where it makes sense to have newer versions on top of a stable base without having to live with a complete rolling stack. I maintain a number of those and none of them have been submitted to Leap by me nor do I have any intention to do so. The two sizes fits all argument is simply not true, no matter how often it gets repeated. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo
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 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 Best regards, seife -- 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
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
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. Steven -- ____________ Apply appropriate technology. Use what works without prejudice. Steven L Hess ARS KC6KGE DM05gd22 Owner Flex-1500 and Flex-3000 Flex-6300, FT-857D, FT-817ND openSUSE Linux 13.1 KDE, Tumbleweed KDE with Packman Known as FlameBait and The Sock Puppet of Doom. -- 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
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
Il 20/10/2015 19:35, Steven Hess ha scritto:
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.
Steven
Minecraft... missing power management and reclocking for almost all cards. My Gt720 and Gt730 are "unknown kepler device" for noveaue. For sure , not corner case.. I'am not a fan of binary blob and closed driver/software but Nvidia drivers just work. Intel drivers are behind the windows version. Still opengl 3.* instead of 4.* Often you need to siwtch back to old accel UXA.. With Ati/amd, mixed results. Some cards work well with free driver, some with catalyst. The tonga/fijy cards are almost unsupported. Daniele. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-20 10:25, Johannes Meixner wrote:
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.
I agree. Many users are content with the initially distributed drivers, and do not need updates if the printers keep working. Only when a user finds his printer does not work, partially or completely, he has a reason to find an update. Forcing that update on all users, via YOU, might break other printers that are currently working fine. Thus the current situation, update via repo when need, is best, in this case, and in many. Not all, and not for everybody. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYmR0gACgkQja8UbcUWM1yX4gEAoPyz5YXGskqeK+US+WLsh3Lx 9yUuKpXzWOqQMH/zvUYA/RJLBiBcZ3C/rseHRl/HtmGJqDwTOLcVdLy7v6Sryri+ =WdPK -----END PGP SIGNATURE----- -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-19 22:08, Greg Freemyer wrote:
Or do we wait for the next SLE 12 Service Pack and have an entire redo of the 42.1 dev process?
Something like that, I understand. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYlT9sACgkQja8UbcUWM1w9cQD+LmNKXSGHDbowEdwrAnWBKg1c JpxAvCGCk3wxpXYOzKYA/0E3VZ0qCXsagRl6v5Cv/d5+9QZ2gJ0eGLsxlyiLFI65 =1Btv -----END PGP SIGNATURE----- -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-19 21:14, Claudio Freire wrote:
On Mon, Oct 19, 2015 at 3:47 PM, Richard Brown <> wrote:
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.
I would agree. Me, for instance, like a stable distro, but I do like to keep LibreOffice more current, as it affects my work. I will, most probably, not update KDE, but I certainly will want to update separate parts; which, I don't know yet. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYlSTMACgkQja8UbcUWM1xz2QEAnuu5HaOnRDEtFNxAP+EB/zV1 3y60TSt7oh0zFj6vZ/oA/3wvJWBo4T1jPz2xRbTwbGhbVyGnzFx+y+C3ncDkfsY1 =yvk1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. Personal experience is just that, personal. I've been using KDE's extra repositories since they exists and haven't got any problem. In fact, in this precise moment I'm using 13.2 + kernel:stable + XOrg without any problem at all (it's just to get the graphics stack current, sort of a experiment because I've already installed Tumbleweed on another partition... but it's been working correctly for some time now). The only factor that I consider important is resources, being human ones the most important for me. If the teams in charge they have the will to keep the great work done I'll sincerely appreciate it. If they stop there will be no complaints for my part, only gratefulness for the work done. It's a user decision what they do or do not install and if we break our installation is our problem, but obviously we have to accept the consequences without any complain! :) Greetings. -- 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:31, jcsl
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? 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... This example kind of illustrates exactly why I'd like to see a de-emphasis on additional repos... -- 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 Mon, 19 Oct 2015 23:57:00 +0200
Richard Brown
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?
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. One reason for the use of a particular additional repo is that the Gnome apps I use on KDE only have their security updates published on the Gnome:Apps repo. -- Graham Davis, Bracknell, Berks. openSUSE 13.2 (64-bit); KDE 4.14.9; AMD Phenom II X2 550 Processor; Kernel: 4.2.3; Video: nVidia GeForce 210 (Driver: nouveau); Sound: ATI SBx00 Azalia (Intel HDA) -- 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
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 --
* Howard Guo
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYmSJcACgkQja8UbcUWM1yr6gD6AyFDZQkAFmiR1ieJlEpkwuPn 412o1tT02W4pJv8CI8EA/R1GGTRF4asRSfVG39Asxn03aM0iaFH4FOCFnNaJmSN+ =pNEP -----END PGP SIGNATURE----- -- 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
* Knurpht - Gertjan Lettink
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.
But working 500 raw photographs does require the nvidia prop driver! nouveau just cannot keep up. -- (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 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
On Wednesday 2015-10-21 00:49, Carlos E. R. wrote:
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.
Except maybe… if you have a software which displays 2D images using a GL context (think `mplayer -vo gl`). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Carlos E. R.
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 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 -- 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
On Wed, 21 Oct 2015 02:09, Carlos E. R.
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
On 21/10/2015 2:37, Yamaban wrote:
On Wed, 21 Oct 2015 02:09, Carlos E. R.
wrote:
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
Yes...
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.
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. You could have just said what you were doing. Displaying a hundred raw photos is not the issue, it is something entirely different. Having a 128 core CPU and working in parallel would also help, way more than a single GPU, I guess ;-) -- 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.
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 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. 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, Oct 21, 2015 at 2:26 AM, Michal Kubecek
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 20/10/2015 17:09, Knurpht - Gertjan Lettink wrote:
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.
To watch video, an Intel does the job fine, you don't need an NVIDIA or AMD.
Yes, absolutely. And for many things - but not all.
Gaming IMHO would be valid.
For instance, Flight Gear flight simulator, doesn't run in my laptop with Intel graphics. It manages to refresh about once or twice a second. That's terrible. -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYnkJgACgkQtTMYHG2NR9UUpwCff6wIKC012w2Hg3fqQn4wK6Yo XCEAn2CsBRM43iSMCzjvg6OOid1f59xa =HkCM -----END PGP SIGNATURE----- -- 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
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. 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 ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
On 2015-10-21 16:13, Knurpht - Gertjan Lettink wrote:
Op woensdag 21 oktober 2015 15:39:41 schreef Carlos E. R.:
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.
Oh, crumbs... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-21 16:11, Knurpht - Gertjan Lettink wrote:
Op woensdag 21 oktober 2015 15:18:19 schreef Carlos E. R.:
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.
I have just installed both in this laptop, and both work. Supertuxkart complains that my video driver is too old. Well, no chance of improving it, it is Intel.
Blender is a good example AFAICT.
Yes, so I hear, but I know about nothing of that thing :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYnt3MACgkQja8UbcUWM1zHOgEAgj0H00aFHSpKFLRBDpJhhLI7 e1OuuAcLKynJMqEB5HIBAJ+qxzSJtRtwPt0UtahPvAXalWoLvGhuw4kCsgI0VDSS =AuZH -----END PGP SIGNATURE----- -- 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
On Wed, Oct 21, 2015 at 03:18:19PM +0200, Carlos E. R. wrote:
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.
Yes, it does. But that doesn't mean I need them. In fact, I never did. Once, I tried for about a week, out of curiosity, but the experience was so awful I felt like trying again.
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:
I dont' know about tuxracer but some time ago, we used to play xonotic in a small group. Worked well enough for me with radeon driver.
Hey, not very long ago (2 yrs?) gnome refused to run without proper acceleration.
Honestly, I never felt like using gnome either. :-) 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. Michal Kubeček -- 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
participants (20)
-
Carlos E. R.
-
Carlos E. R.
-
Claudio Freire
-
Daniele
-
Dominique Leuenberger / DimStar
-
Graham P Davis
-
Greg Freemyer
-
Howard Guo
-
Jan Engelhardt
-
jcsl
-
Johannes Meixner
-
Knurpht - Gertjan Lettink
-
Michael Ströder
-
Michal Kubecek
-
Patrick Shanahan
-
Richard Brown
-
Robert Schweikert
-
Stefan Seyfried
-
Steven Hess
-
Yamaban