Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation
Absolutely. Indeed it should. Not only for different types of users, but for different trails as well. Again I use Unity as example. Suppose you want to start developing. You've covered the basics of the language, and now you want make something you can show your friends. So you do to the docs page developing Python Desktop Unity. There you find the Unity Specification 1.0 Documentation, with Indicators, Launcher, and everything. You learn how to make lenses and scopes, and there's lots of them to make in your area, so you just keep going and become really good at it. Then you begin to wonder how it works under the scene. So you go to the next level, which is the DBus architecture. You're still on the same trail, mind you. So you lean how the DBus bindings work in Python and then you move on to the DBus Unity API itself. That's the exact same document you'd end up with if you'd started with Vala, because after all, it's the same thing. If you've followed the Python trail already, you'll just get the Oh, I know this! feeling, which isn't a bad thing. So the main documentation tree might be grouped in libraries and then under language, as is the case on dev-u-c now, but to the user, it'll be presented by their interests, as trails. The documentation isn't just something that comes with the tools. The documentation itself is its own product with its own goals. Here's an example for you; I recently switched to BtrFS in Precise. I needed to learn, and I ended up here: https://help.ubuntu.com/community/btrfs. As far as I can tell, there's nothing particularly wrong with that information. But then, this stuff is new to me, so how would I know? It doesn't inspire confidence. Ubuntu-specific subvolume layout in 11.04 and later? I'm using 12.04! But I'm very familiar with this, so I scrolled down towards the bottom of the page to see when it was last updated. Just a few days ago. Nice. And I can see the page history. On my way there I noticed that most of the information is for 8.10! This is a filesystem we're talking about. I really need to be confident about this information, and the mere mention of 8.10 makes me suspicious. This page was marked out of date nearly four years ago: https://wiki.ubuntu.com/UbuntuOnMac. Why does it even exist? I assume it's simply because noone has the overview to systematically make sure pages like that is either updated or deleted. If noone has an overview, then it's difficult to attract contributors as well. Specific tasks makes it much easier. And by update, I don't mean adding new info on top, leaving older info below. One page per version. Reviewed. Obviously Valid. Facts aren't good enough anymore. We need to design documentation for the user. And that can't just be about deleting old wiki pages. We need a goal. A new way of thinking about documentation as a whole. Jo-Erlend Schinstad -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] Quality, testability for the desktop components
Sebestien, Are you looking for discussion on these topics on this list? If so, I would suggest that Libre Office might be a good candidate for us to offer regular integration tests. I know that Libre Office has a test suite, it might be very useful to run these tests daily on Ubuntu (to discover when Ubuntu breaks LO) and it might be useful to run tests on upstream changes (to discover when LO breaks Ubuntu). Thoughts? Cheers, Rick On Wed, Apr 18, 2012 at 10:39 AM, Sebastien Bacher seb...@ubuntu.comwrote: Hey, The Canonical upstream teams did some good progresses on testing and quality this cycle, that's a good step for the Ubuntu Desktop quality, we still rely on quite some components from other upstreams though that didn't engage into a such process yet though (those who looked at gnome-settings-daemon, nautilus, gvfs, etc bugs on launchpad probably know what I mean there). I would like to see if we can work on our side and with upstream to get those automated tested in some ways. It would be also nice to see regular run and report of the testsuits for other components which already have one (i.e glib, gtk) and some testing of their rdepends before upload. Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.**com ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/**mailman/listinfo/ubuntu-**desktophttps://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: {Desktop 12.10 Topic] Holistic approach to Ubuntu documentation
On 19 April 2012 02:51, Jo-Erlend Schinstad joerlend.schins...@ubuntu.com wrote: Den 19. april 2012 03:11, skrev Jeremy Bicha: Your topic mixes developer docs, entry-level user docs, and power user docs. Each of those needs a different approach and I think it's simpler to tackle them as three mostly separate things. Also, if you're going to discuss documentation, you should probably include the docs team (CC'd now) as that's where people interested in that read. The point is the exact opposite. We shouldn't split documentation up into completely unrelated pieces. That is the problem. I don't agree with this, and I agree with Jeremy. The fact that information provided to help users (help.ubuntu.com), information provided to help application developers (developer.ubuntu.com) and information provided to help contributors (wiki.ubuntu.com) could all be given the single label documentation or indeed information is just a matter of language. The three concepts are so fundamentally different that they justify and require a completely different approach, different websites and even a different authorship. It's not useful to think of them as different aspects of the same thing. They aren't. This is particularly important for users. We mustn't burden users looking for help with Ubuntu with the sort of complex and confusing information that is found on wiki.ubuntu.com or developer.ubuntu.com. We worked quite hard back in 2006 to separate these concepts out (https://wiki.ubuntu.com/BetterWikiDocs) and I think it's important that we stand by it. Furthermore, the type of information being presented to users is so different to that presented to developers that it warrants different structure and a different style. As to authorship, developer material is usually best written by developers, because they know what they are talking about and have been through the process of learning about those concepts, whereas it's less common (albeit not impossible) that developers make good authors of user help because there the level of knowledge required is different, and the focus is on the skill of explaining something to a non-technical user in the most effective way. So good writers of user help are often non-technical people themselves. Having said that, I think that you also make a perfectly valid, point about the validity, quality and process used to updating documentation. Nothing I have said above is intended to suggest that we have a good process for user documentation - there is vast scope for improvement almost at every level, both in the structure of the user documentation, the quality of it, the number of contributors attracted, and so on. However, these types of points are entirely separate from the main point which you make about eliding different types of documentation. In relation to quality and process, you give a few specific examples of pages which are out of date and which are difficult to rely upon. I've no doubt you could have given dozens of examples. On the help wiki, we do have a way which has been established of dealing with such pages: https://help.ubuntu.com/community/Tag For example, you mentioned this page: https://help.ubuntu.com/community/btrfs You're right that it seems to be drafted for older versions of Ubuntu, so I've added the unsupported tag. Your point of course would be that when you visited that page, in the role of a user, you weren't to know that the page could be out of date. And you're right that it would be useful to discuss whether there could be some kind of systematic process whereby pages are reviewed and updated on a regular basis, or whereby users themselves can report problem pages more easily than they can now. Any such discussion has of course to take into account the fact that there are actually not a lot of contributors to documentation. It therefore needs to be coupled with a separate discussion about how to attract more contributors. Such a discussion would be very useful. There are plenty of new ideas and approaches we could consider with a view to improving the user documentation. -- Matthew East http://www.mdke.org gnupg pub 1024D/0E6B06FF -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] Quality, testability for the desktop components
On 04/18/2012 10:39 AM, Sebastien Bacher wrote: It would be also nice to see regular run and report of the testsuits for other components which already have one (i.e glib, gtk) and some testing of their rdepends before upload. Almost a year ago, I wrote a short summary on current situation with Ubuntu and about a few ideas on how to make things better [1]. Some of that stuff is already obsolete, but some is still valid. My point was, if Ubuntu is a community project, then QA should also be a part of community. The problem with testing is that it is annoying, something that you have to do and a lot of times it is quickly dismissed by people that don't belong to the ugly corporate world. Which is sad. I was thinking about a certification system for programs and this system would also require some testing and QA for the programs. I believe that people need to be motivated for writing all those tests. And before they start, they need some guidelines on how this is done, what is required and so on. Something similar to what Jono is now doing with Achievements, but for applications, programs, components, not for people. [1] http://www.twm-kd.com/linux/made-for-ubuntu-certificate-proposal/ Regards, David -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 12.10 Topic] GNOME plans review
Hey, Not sure how much we need to discuss but it's always good to have a GNOME checkpoint session. It's likely that this cycle we will not hold back on things we kept behind until now, which means we need to bring clutter on the CD and see how we do that and what it means (do we need extra testing on some platforms during the cycle, how will it work for people not having 3d working, etc). Some other desktopish topics I would like to discuss, not sure if that's the right session but since we will probably have time in that one: - our delta with upstream and Debian and how we could lower it? mpt suggested that launchpad-integration items are quite geeky, they also create most of our diff over Debian and extra work and don't really scale since they require sources patching, maybe it's time to discussion dropping that? - tools, though UDD didn't change a lot so I don't think the consensus will be any different from what it was other cycles - whatever other topics you guys come with ;-) Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 12.10 Topic] Replace system-config-printer by the GNOME printing panel
Hey, That's somewhat a leftover from this cycle, I know Lars has been working on getting the GNOME tools at feature parity, or at least to be useful enough to be able to use it instead of the system-config-printer gui, he was close of having it ready this cycle so I guess it should be fine for next cycle. Not so much desktop work there I guess since Lars and Till should have that under control... Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] GNOME plans review
Le 19/04/2012 12:28, Sebastien Bacher a écrit : - whatever other topics you guys come with ;-) We should probably have a discussion about gnome-control-center with design, our delta there and the strategy going forward to maintain it. We either need to work with upstream and get stuff merged back there even if that's not exactly what our design team wanted or to decide to maintain our forked ubuntu-control-center version with the additional cost that represents. Not sure if that should have its own session though... Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop 12.10 Topic] System compositor
Hi, A change I'd like to make for 12.10 is to use a compositor to control video from boot to shutdown. This gives us the following benefits: - We can have smooth transitions from the splash screen to the greeter to the session and back again - We don't use VT switching anymore which has been shown to be problematic - We use one consistent monitor layout for all stages of the boot - We can use the greeter as the lock screen (couldn't get it to work this cycle for the above reasons) - We can ensure that you can never accidentally switch to a locked session - We can show the greeter while the session loads The technology used will probably be Wayland, and in some ways this change is to implement the Wayland Tech Preview that was proposed for Precise [1]. Note that not all video drivers will support this, and we will continue to support the current system for those that do not support it (primarily the nvidia driver). --Robert [1] https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-wayland-tech-preview -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] GNOME plans review
On 04/19/2012 06:28 AM, Sebastien Bacher wrote: - our delta with upstream and Debian and how we could lower it? mpt suggested that launchpad-integration items are quite geeky, they also create most of our diff over Debian and extra work and don't really scale since they require sources patching, maybe it's time to discussion dropping that? Assuming launchpad-integration means the added menu items, this could possibly be added at runtime by the global menu, rather than patching the app source. Michael Hall mhall...@ubuntu.com -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] Quality, testability for the desktop components
On Thu, Apr 19, 2012 at 11:17:21AM +0200, Sebastien Bacher wrote: I agree that libreoffice would be a good fit, especially if it has a test suite already. Bjoern, do you think it's feasible? Yes, I had a call about that with the QA team already. There are multiple ways this could be done. Im in a hurry right now, I will reply back with more details later tonight. Best, Bjoern -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] The future of third-party driver installation
Den 18. april 2012 09:14, skrev Martin Pitt: Hello Desktop fans, We have had Jockey for quite a while now to perform the installation of proprietary (e. g. NVidia), alternative (e. g. fglrx vs. fglrx-updates), third-party (e. g. from openprinting.org) drivers. Hardware! Yes, that's an area where large improvements can be made. The ability to easily install third-party drivers is obviously quite valuable. But how do people actually look at drivers? I don't think most people understands the difference between open drivers and proprietary third-party drivers. Nor do I think they care. And why should they? What they want, is for their hardware to work properly. If this was going to be redesigned, I would rather see it as a Hardware manager. Ubuntu is currently promoting drivers as an optional extra. But that's not true; drivers are always necessary for all hardware. One problem with doing that, is that when you're missing an important driver and it's not available in Jockey, then you get the impression that Ubuntu has no drivers for your system. Reality is that Ubuntu has nearly all of your drivers, but missing one. Users should see that. Otherwise, we're always reinforcing the negative without showing anything positive. The moon looks smaller when it's near the horizon, because you have something to compare it to. So let's compare the one thing that doesn't work with the huge number of things that does. If changes are to be made, I would propose that it displayed all your hardware, what drivers it is currently using and then make it easy to install other drivers. From this application, you should be able to export your hardware info so that you can easily provide this to support. (System Info Hardware Manager Send To: pastebin | email | IM | etc). That is to say, even if your computer doesn't require any proprietary drivers, the application should still be useful. It would then display the drivers, the developer being listed as Linux. If there are alternatives, or third-party drivers are required, then you should be able to easily install them. As a service to the user, this application should also provide links to the manufacturers website for further support. This would both be helpful to the user, and show who's responsible. In other words; We have installed all your drivers for you automatically, except that one. Perhaps this application could also be used to try and find out which computer model you have, and provide some kind of forum where you can connect to other users with the same hardware? That way, people can share their experiences, and support would be able to help a large number of people at the same time, instead of each user having to begin with a Google search and go from there. That would enable automatic detection of some troublesome hardware as well, because it would automatically get many posts. This wouldn't have to be fully automatic, but it should be possible to limit the number of possible models based on the hardware. Then you can look through a photo album to make it easier to spot your model. If you can't find it, then you can upload an image of your own, and then people could help identify that computer, enabling you to more easily get support – improving Ubuntus database of models at the same time. Right now, driver support seems bad in Ubuntu. It's actually awesome. We need to display it as such. When drivers can't be provided at all, it must be obvious to the user who is responsible for that and preferably how to contact them. Don't you think? Jo-Erlend Schinstad -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] Quality, testability for the desktop components
Hi all, On Thu, Apr 19, 2012 at 11:17:21AM +0200, Sebastien Bacher wrote: I agree that libreoffice would be a good fit, especially if it has a test suite already. Bjoern, do you think it's feasible? So, we have 3 possible sources of bugs/regressions/test failures for LibreOffice on Ubuntu: - LibreOffice Upstream (http://cgit.freedesktop.org/libreoffice/core/) - Ubuntu platform (that is: all the packages that LibreOffice depends on directly or indirectly) - LibreOffice packaging itself (http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=summary) As for test suites, at LibreOffice we have multiple ones: 1) unittests - run during the build - most cant run against an installation, because they are depending on symbols that are not exported - easy to debug 2) smoketest - basic integration test - runs against an installation - hard to debug 3) complex tests - manually written tests in junit that specific scenarios over the UNO-API - runs against an installation - unusally good test code, but limited coverage - harder to debug (test and tested code in different processes, UNO-bridge) 4) unoapi tests - automatically created tests that test every UNO-interface - rather mechanical test code, but better code coverage - runs against an installation - harder to debug (test and tested code in different processes, UNO-bridge) 5) testtool tests (defunct) - testing LO/OOo by hooking into the toolkit and creating synthetic event - fragile - unreliable - unmaintainable - runs against an installation - hard to debug - defunct now at LibreOffice (good riddance!) 3+4 together are also called subsequenttests see http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/8746 for details. So what do we do now? During each build we run the tests 1,2,3 and 4, but 2-4 against an installation _before_ we pack the product. That helps us against bugs/regressions caused by changes in: - LibreOffice Upstream - Ubuntu platform at the time of the build it does not find all bugs in LibreOffice packaging as these tests are run _before_ packing. What can we do additionally? 1) just build the latest LibreOffice package available daily or weekly This would show us if there is a bug/regression/test failure caused by an updated package. LibreOffice has been ftbfs multiple times already by innocent looking updates to its dependencies (which are a lot). I consider building the LibreOffice package a testcase in itself, esp. since a lot of tests are run during that. 2) build the latest LibreOffice package available with a brand new checkout of the upstream sources. This would help detecting breakages early from upstream changes, but I think that would not make sense to do before the release branch is branched off (too instable, too much adjustment in packaging needed before branchoff). see http://wiki.documentfoundation.org/ReleasePlan/3.6 for details: branchoff is scheduled for Week 23, 2012 (starting June 4th, 2012) around Alpha1 3) Run tests against a version packed and unpacked/installed into the system. This would be the tests 3+4 from above. This would finally also cover the LibreOffice packaging itself. This would still need a build and an installation. 4) Provide a tinderbox to LibreOffice upstream: http://tinderbox.libreoffice.org/MASTER/status.html This would esp. make sense for example for armhf or somesuch to see nasty platformspecific breakages early (those are mostly independant from packaging, which this would not test). What do I think to be sensible? IMHO: 1) until branchoff of the release branch 2) from branchoff 3) all the time 4) all the time I think we will find a lot of stuff just by building LibreOffice regularly (1+2) -- it is a rather good test case and easy/trivial to implement, even though it is not exactly ressourcefriendly (although when using ccache and not building all l10ns, it shouldnt be too hard on modern hardware). 3 would be a bit more work to implement, and might be questionable in the long term as the Junit/UNO-Tests are not expected survive the LibreOffice-4.0-API change without much work. Still, if we do 1 and 2, it should not be too much additional work. 4 is rather indepedant of 1-3, still worth considering. I would have to choose just one because of hardware limitations, I would go for: 1 up until branchoff, 2 from there -- both with ccache(*) and limited l10n. I believe that would give us already some very good coverage compared to what we have now. I will create a blueprint for UDS-Q this. Best, Bjoern (*) ccache cleared weekly to catch errors by compiler updates -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] The future of third-party driver installation
On Fri, Apr 20, 2012 at 01:56:53AM +0200, Jo-Erlend Schinstad wrote: If this was going to be redesigned, I would rather see it as a Hardware manager. Ubuntu is currently promoting drivers as an optional extra. But that's not true; drivers are always necessary for all hardware. One problem with doing that, is that when you're missing an important driver and it's not available in Jockey, then you get the impression that Ubuntu has no drivers for your system. Reality is that Ubuntu has nearly all of your drivers, but missing one. Users should see that. Otherwise, we're always reinforcing the negative without showing anything positive. It's a good point. And in fact you're right, updates for various non-proprietary drivers are available to users. A good case in point being the x-updates ppa which provides updated X video drivers. And you're right that this is less visible than the fglrx/nvidia updates that come through jockey. Now, drivers provided via a ppa is not the same thing, but from a user's perspective I don't think they really draw a distinction. Newer == better. I kind of worry that partly because we don't have a rolling update, users end up seeking out updates from highly unofficial channels... xorg-edgers, kernel mainline ppas, even installing drivers from third party sites like amd.com and nvidia.com. Half the fglrx and nvidia bug reports we see are a result of some sort of mix-and-match cobbled together system that inevitably breaks in some oddball way. Anything we can do to guide such users towards more sane update solutions would be a positive in my book, so long as doing so doesn't incur additional support workloads. If changes are to be made, I would propose that it displayed all your hardware, what drivers it is currently using and then make it easy to install other drivers. From this application, you should be able to export your hardware info so that you can easily provide this to support. (System Info Hardware Manager Send To: pastebin | email | IM | etc). This is a very interesting idea. Already we have tools scripts and apps scattered hither and yon that gathers this info. Would be nice to have it in a simple, parseable form (maybe a text file somewhere in /var?) might help in a lot of areas. That is to say, even if your computer doesn't require any proprietary drivers, the application should still be useful. It would then display the drivers, the developer being listed as Linux. If there are alternatives, or third-party drivers are required, then you should be able to easily install them. As a service to the user, this application should also provide links to the manufacturers website for further support. This would both be helpful to the user, and show who's responsible. In other words; We have installed all your drivers for you automatically, except that one. Yes, it would be important in a tool like this to make sure it guides people *away* from unsupportable configurations, and makes it clear if they insist on doing it anyway, that it taints their system and may incur other bugs that we can't really fix. In fact, if this tool could communicate the level of taintedness of the system, that might be usable in the apport bug hooks to prevent bugs from being filed to us on such systems. At the same time, for users who aren't as worried about this or who have hardware that simply wasn't properly supported at the time of the release, it'd give them an extra avenue for testing out alternative versions to work around problems or improve their hardware performance, while giving them a measurable way for what'd need done to restore the system to stock. Perhaps this application could also be used to try and find out which computer model you have, and provide some kind of forum where you can connect to other users with the same hardware? That way, people can share their experiences, and support would be able to help a large number of people at the same time, instead of each user having to begin with a Google search and go from there. That would enable automatic detection of some troublesome hardware as well, because it would automatically get many posts. Interesting idea. This could possibly be handy as an os maintainer too. Receive a new computer and pull up a listing of all bugs specific to that system's particular combination of hardware and drivers. Bryce -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop 12.10 Topic] The future of third-party driver installation
On Thu, Apr 19, 2012 at 7:56 PM, Jo-Erlend Schinstad joerlend.schins...@ubuntu.com wrote: Den 18. april 2012 09:14, skrev Martin Pitt: Hello Desktop fans, We have had Jockey for quite a while now to perform the installation of proprietary (e. g. NVidia), alternative (e. g. fglrx vs. fglrx-updates), third-party (e. g. from openprinting.org) drivers. Hardware! Yes, that's an area where large improvements can be made. The ability to easily install third-party drivers is obviously quite valuable. But how do people actually look at drivers? I don't think most people understands the difference between open drivers and proprietary third-party drivers. Nor do I think they care. And why should they? What they want, is for their hardware to work properly. Hmm. I think you should be careful not to jump to conclusions here. You may run into a lot of trouble coming to consensus among the community, or even among the Ubuntu developers, regarding this point. Don't take it for granted that everyone will turn a blind eye to proprietary software running on their system. A lot of people think it is important to remind our users that the *reason* why their OS runs so well is because the vast preponderance of its software is free and open source software. Licensing matters -- whether or not you agree with that point, licensing nonetheless matters to a lot of people, and whitewashing the subject will not be an easy sell. All I'm saying is that you're touching on a very controversial issue here, and regardless of what I personally believe or how convinced you may be of your own opinion, realize that you can expect resistance from various people if you're going to say why should users care whether their drivers are open source or proprietary?. People will give you reasons why -- reasons that they feel very passionately about. Just be prepared. ;) Instead, a good compromise would be to provide the user a summary of the pros and cons of using proprietary drivers without making it overly complex. You almost have to take it on a per-driver basis, because it really does vary (aside from the fact that Ubuntu developers can't directly support or enhance or fix bugs on proprietary drivers; this point is going to be the same for all proprietary drivers). But for other drivers like fglrx, there are issues such as whether kernel mode setting is supported, the expected 2D performance, the expected 3D performance, the expected stability, and so on. If we could somehow capture these points in a user-accessible way and allow the user to make an informed decision, that would be better than trying to *over-*simplify and make a decision for them, whether that decision is in favor of open drivers or proprietary ones. Because remember, it's hardly a foregone conclusion that proprietary drivers are always going to work better or be more stable. It really depends on the use case. For instance, there was an EIGHT MONTH period where I could get a solid 60 fps with 100% stability from the radeon open drivers playing my favorite game (Savage 2), but it would crash on startup with the proprietary fglrx. This continued, as I said, for eight successive monthly releases of fglrx. But on the flip side, there were many applications that would lock up the whole system if started with the open drivers, but fglrx would render them decently well. We're going to be shipping drivers with really nasty tradeoffs like this for years and years to come, and if we don't deal with the complexity, the users will deal with it the only way they can: they will ignorantly claim, Ubuntu sucks! as soon as their system or some program crashes for *any* reason. Complex problems require complex reasoning, even with licensing itself completely out of the picture (and the licensing debate will open a whole new can of worms by itself). If this was going to be redesigned, I would rather see it as a Hardware manager. Ubuntu is currently promoting drivers as an optional extra. But that's not true; drivers are always necessary for all hardware. One problem with doing that, is that when you're missing an important driver and it's not available in Jockey, then you get the impression that Ubuntu has no drivers for your system. Reality is that Ubuntu has nearly all of your drivers, but missing one. Users should see that. Otherwise, we're always reinforcing the negative without showing anything positive. The moon looks smaller when it's near the horizon, because you have something to compare it to. So let's compare the one thing that doesn't work with the huge number of things that does. Are you basically suggesting a shameless clone of the Windows Device Manager? Not a terrible idea, if it can be executed well. And I mean *well*. Linspire had a similar thing a few years back, but it was abysmal: you couldn't get any real information from it, and the information that *was* there was very technical and inscrutable to end users. It also didn't tell you whether
