Re: Standardised Hardware Support Spec - Please Review
From my perspective, it would be better to create a cross distro list of hardware compatibilty. This would show which pieces of hardware work and which don't. The benefits of this are legion, but here are the main ones: 1. Single database for new linxu users to look in 2. Single database to point vendors at in an attempt to get them to understand how large their Linux base really is I've been thinking about starting a project just like this for a long time. If anyone is interested, please let me know! Maybe it would be good to only target ubuntu at first, and later expand the focus. Probably the best candidate for this is the new LHCP from Fedora, which is very similar to the Hardware DB Ubuntu has, but has a scope of more than just Ubuntu. As such, I would create a spec about getting the common client in Ubuntu. The LHCP project, while it sounds interesting, doesn't seem to be active at all, judging by the mailing list activity. Ciao Paulus -- Ubuntu-devel-discuss mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
On Thu, 2007-04-05 at 21:39 +0100, Matt Zimmerman wrote: On Thu, Apr 05, 2007 at 09:24:19PM +0100, Alex Jones wrote: (As a side thought, I'm not sure what constitutes common hardware, but I for one don't know a single person who owns a Palm device.) I can see two or three Treos from here. Whether they work with gnome-pilot is another story, but if gnome-pilot doesn't work with a significant share of current devices, the solution would be to remove it from the default install, not add a new application to help the user remove it. You wouldn't necessarily /need/ a new application to help the user remove it if it was packaged like I am suggesting. You'd remove the HSP and the installed and unneeded support packages could be apt-get autoremove'd. Sorted. As it happens, all of this stuff is just dependency of ubuntu-desktop, meaning that it all gets reinstalled every time I do a distribution upgrade. *Groan*. I've noticed that in my restricted drivers manager, it has chosen to install Lucent/Agere lindmodem controller driver. I didn't even think I had a modem, and even if I did, I certainly have zero use for it. What's the point in knowingly infecting my system with closed-source kernel modules when you don't even know if I want it? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
On Fri, 2007-04-06 at 06:48 -0500, hggdh wrote: On Fri, 2007-04-06 at 08:56 +0100, Alex Jones wrote: You wouldn't necessarily /need/ a new application to help the user remove it if it was packaged like I am suggesting. You'd remove the HSP and the installed and unneeded support packages could be apt-get autoremove'd. Why not create this database, create an interface to HAL, and then just start what is signaled from HAL? This way we can still have a distro that will allow the casual user to just plug and play -- which is, I think, quite an important thing to have. This isn't about running unnecessary services, it's about having them installed on your system in the first place. On the other hand, I am not sure that I would like to have generic autostart on a server. And, no matter what, I would really like *not* to have autostarted what I do not want started, for whatever reason. We should have an easy way of doing so. Having said what I've just said above, it would be nice if, whenever you hotplug a device, it gives you the option of what to do next, in a way similar to what happens when you plug removable media in. Sorted. As it happens, all of this stuff is just dependency of ubuntu-desktop, meaning that it all gets reinstalled every time I do a distribution upgrade. *Groan*. Yes, that bothers me also. And, on some servers, I do want X (for example). Not sure what you're getting at here. You /do/ want X? Why is it a problem to remove ubuntu-desktop there, then? I've noticed that in my restricted drivers manager, it has chosen to install Lucent/Agere lindmodem controller driver. I didn't even think I had a modem, and even if I did, I certainly have zero use for it. What's the point in knowingly infecting my system with closed-source kernel modules when you don't even know if I want it? Well, with all due respect, you already have infected your system with closed-source module(s). I have? (Not that I'm normally that bothered about it.) But I do see your point and, again, an interface with HAL plus a DB could deal with it. As for the packaging of all the restricted modules together, I have no opinion. Personally I don't see the reason to bundle restricted drivers together at all. In my opinion, we should have supported HSPs that are provided by Ubuntu/Canonical, and unsupported HSPs that can be provided by third parties. All of the current restricted drivers would be of the unsupported kind. I think this is a much more logical approach to everyone, including non-technical end-users. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
RE: Standardised Hardware Support Spec - Please Review
-- Forwarded message -- From: Christoffer Sørensen [EMAIL PROTECTED] Date: Apr 6, 2007 2:37 PM Subject: Re: Standardised Hardware Support Spec - Please Review To: Alex Jones [EMAIL PROTECTED] On 4/6/07, Alex Jones [EMAIL PROTECTED] wrote: On Fri, 2007-04-06 at 06:48 -0500, hggdh wrote: On Fri, 2007-04-06 at 08:56 +0100, Alex Jones wrote: You wouldn't necessarily /need/ a new application to help the user remove it if it was packaged like I am suggesting. You'd remove the HSP and the installed and unneeded support packages could be apt-get autoremove'd. Why not create this database, create an interface to HAL, and then just start what is signaled from HAL? This way we can still have a distro that will allow the casual user to just plug and play -- which is, I think, quite an important thing to have. This isn't about running unnecessary services, it's about having them installed on your system in the first place. Great idea. I second it. On the other hand, I am not sure that I would like to have generic autostart on a server. And, no matter what, I would really like *not* to have autostarted what I do not want started, for whatever reason. We should have an easy way of doing so. Having said what I've just said above, it would be nice if, whenever you hotplug a device, it gives you the option of what to do next, in a way similar to what happens when you plug removable media in. This is another spec, I think. Personally I don't see the reason to bundle restricted drivers together at all. In my opinion, we should have supported HSPs that are provided by Ubuntu/Canonical, and unsupported HSPs that can be provided by third parties. All of the current restricted drivers would be of the unsupported kind. I think this is a much more logical approach to everyone, including non-technical end-users. I think it makes sense for network cards, since you cannot download anything if the network is not working. I think your idea is good, but who is going to produce these HSPs? If this is going to be something that should not fail, then we need man power. Creating, testing, fixing these HSPs requires some work. However, the current approach is not perfect. Having HPLIP, PalmOS support, when I don't even have those devices is not that great. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
On Fri, 2007-04-06 at 15:20 +0100, Matt Zimmerman wrote: restricted-manager is needed because of the special requirements of the restricted driver setup. It ties together the X server configuration, kernel modules, licensing, the package system, etc. It would be preferable if they didn't require such complex handling, but for now this is the best solution available. Yes, it does a good job of taking care of the rough edges for now, but these rough edges /could/ be better taken care of. Similarly, I don't see how a new set of metapackages for every supported device (even if that were possible) helps to simplify this. You say that as if it isn't possible. Why? Because of the size and rate of change of this data. Who would collect, formalize and maintain it, and how? Tens of thousands of devices are supported by Ubuntu. The metapackage generation would be done by using the hardware database. It wouldn't be much work to add a new hardware device to the database, and then officially say it is supported in order to do a number_of_devices_supported++. And I suggest it helps to simplify this because currently if I want to install an exotic piece of hardware that isn't supported out of the box, I may have to chase down several different packages if there isn't a metapackage to bring it all together for me. The examples you've provided so far are all for common devices, where I think that providing support by default is a more effective option. Do you have particular devices or packages in mind here? Your proposal includes as an example a metapackage which depends on: - The USB storage kernel driver - an 88k module included with the kernel supports hundreds of different devices by default - The HAL FDI data for your phone - 140k of similar data included in the hal package covers hundreds of devices by default - Icons from Tango - I'm not sure which ones you mean, but Tango includes thousands of icons which are generally a few kilobytes each, and the hardware-related ones apply mostly to a wide range of devices I don't see the value in splitting these into separate packages; the current scheme works very well and is much simpler. The package metadata and maintenance overhead would easily outweigh finer granularity for the end user. Perhaps I am expecting more flexibility from Ubuntu than I should be. If I want USB mass storage purged from my system, I'd currently have to roll my own kernel packages. Yes, this is a corner case. I just thought it would be useful to someone to support it. Can you tell I run Gentoo on other systems? Stop laughing. If all of the hardware in the world was supported in Ubuntu (even if that were possible :P), by both Linux kernel modules, and by the huge number of userspace services and configuration tools required (/further/ padding out the default System Preferences menu), then no, this wouldn't be an issue. I leave it to anyone who reads this to decide if it is an issue or not. I don't think there is a tangible general problem to be solved here, and that the issues you raise are likely to be more easily addressed directly (as with gnome-pilot) rather than by new infrastructure. How do you address the gnome-pilot issue? Uninstall it when you /don't/ have the hardware? Unfortunately, hal and udev don't support not-plugging yet. I was primarily answering the question you asked above. The reason this driver is on your system is that some users do need it, and the approach we've taken in Ubuntu is to support a wide range of hardware by default. This involves a tradeoff in disk space and (occasionally) a menu item, in exchange for simplicity. I just find it a completely unintuitive pain in the butt to keep my Ubuntu system lean. I just want to say I only want support for this set of hardware. Everything else, get out. Other distributions take different approaches to this problem. Guadalinex, for example, uses a system called Hermes, which dynamically installs new packages when hardware is detected. This is very much along the lines of your proposal, and so perhaps that project would be a good place to explore these ideas. I tried to get some info on Hermes but everything I find is in Spanish. :/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
On Fri, Apr 06, 2007 at 04:37:19PM +0100, Alex Jones wrote: On Fri, 2007-04-06 at 15:20 +0100, Matt Zimmerman wrote: Similarly, I don't see how a new set of metapackages for every supported device (even if that were possible) helps to simplify this. You say that as if it isn't possible. Why? Because of the size and rate of change of this data. Who would collect, formalize and maintain it, and how? Tens of thousands of devices are supported by Ubuntu. The metapackage generation would be done by using the hardware database. It wouldn't be much work to add a new hardware device to the database, and then officially say it is supported in order to do a number_of_devices_supported++. The hardware database does not contain information about packages, only the hardware present in the system (and a few other bits). It gives us an idea of which devices are being used with Ubuntu and whether they are well supported. I don't think there is a tangible general problem to be solved here, and that the issues you raise are likely to be more easily addressed directly (as with gnome-pilot) rather than by new infrastructure. How do you address the gnome-pilot issue? Uninstall it when you /don't/ have the hardware? Unfortunately, hal and udev don't support not-plugging yet. By allowing the user to uninstall it if they desire, without interfering with the metapackage infrastructure. I was primarily answering the question you asked above. The reason this driver is on your system is that some users do need it, and the approach we've taken in Ubuntu is to support a wide range of hardware by default. This involves a tradeoff in disk space and (occasionally) a menu item, in exchange for simplicity. I just find it a completely unintuitive pain in the butt to keep my Ubuntu system lean. I just want to say I only want support for this set of hardware. Everything else, get out. We're working toward an ideal of everything simply works for as many people as possible, while what you seem to be after is I have exactly what I want, no more and no less. While these aren't necessarily in conflict, in practice they result in different priorities for a project. Gentoo, and more recently rPath, are pursuing the latter approach, as is (to a lesser extent) Debian. -- - mdz -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
On Wed, Apr 04, 2007 at 12:57:06PM +0100, Alex Jones wrote: This comes about as more and more people question why their computer starts bluetooth services when they don't have a bluetooth device, or why I have a HP printer driver control panel applet, or a Palm Pilot sync applet, or PCMCIA services, etc. etc. etc... This was a conscious decision. Our belief is that users should not need to find or install additional software to make use of common devices. They should just work out of the box. If your intent is to suggest a way to address the problem of superfluous menu items, a better way to do that would be to investigate hiding the menu items unless the relevant hardware is detected (via HAL). -- - mdz -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
On Thu, 2007-04-05 at 12:10 -0700, Corey Burger wrote: On 4/4/07, Alex Jones [EMAIL PROTECTED] wrote: This comes about as more and more people question why their computer starts bluetooth services when they don't have a bluetooth device, or why I have a HP printer driver control panel applet, or a Palm Pilot sync applet, or PCMCIA services, etc. etc. etc... https://wiki.ubuntu.com/StandardisedHardwareSupport Please let me know what to do next. Thanks! -- From my perspective, it would be better to create a cross distro list of hardware compatibilty. This would show which pieces of hardware work and which don't. The benefits of this are legion, but here are the main ones: 1. Single database for new linxu users to look in 2. Single database to point vendors at in an attempt to get them to understand how large their Linux base really is Probably the best candidate for this is the new LHCP from Fedora, which is very similar to the Hardware DB Ubuntu has, but has a scope of more than just Ubuntu. As such, I would create a spec about getting the common client in Ubuntu. Something akin to Wine's AppDB would be fantastic. Corey -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
On Thu, Apr 05, 2007 at 09:24:19PM +0100, Alex Jones wrote: (As a side thought, I'm not sure what constitutes common hardware, but I for one don't know a single person who owns a Palm device.) I can see two or three Treos from here. Whether they work with gnome-pilot is another story, but if gnome-pilot doesn't work with a significant share of current devices, the solution would be to remove it from the default install, not add a new application to help the user remove it. -- - mdz -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Standardised Hardware Support Spec - Please Review
I'm probably way out of my element, here, but wouldn't the ideal solution be to load services based on what hardware is present. And by what hardware is present, I don't mean at install or boot-up; I mean it in general (i.e., if someone plugs in an HP printer, then the HP printer service(s) will get loaded). I don't know for sure that this isn't already happening to some extent, but I just checked to see if I have any superfluous services running, and I found a Graphic tablets management service running, which I doubt that I need. Is that not the sort of thing HAL was intended for? Or perhaps this would require another little service on top of HAL that has access to a hardware database and information about what services (and packages?) are relevant for each device (?). This would at least avoid the extra services. You would still have the problem of extra software installed for a few of the more important things (HP printers, Bluetooth, ...). Alex's proposal my be good for dealing with that, though, for the few who are concerned. On Thu, 2007-04-05 at 21:24 +0100, Alex Jones wrote: On Thu, 2007-04-05 at 19:58 +0100, Matt Zimmerman wrote: On Wed, Apr 04, 2007 at 12:57:06PM +0100, Alex Jones wrote: This comes about as more and more people question why their computer starts bluetooth services when they don't have a bluetooth device, or why I have a HP printer driver control panel applet, or a Palm Pilot sync applet, or PCMCIA services, etc. etc. etc... This was a conscious decision. Our belief is that users should not need to find or install additional software to make use of common devices. They should just work out of the box. If your intent is to suggest a way to address the problem of superfluous menu items, a better way to do that would be to investigate hiding the menu items unless the relevant hardware is detected (via HAL). I'm /not/ suggesting we don't install a core set of hardware support software by default. I am suggesting that users be given a choice by packaging drivers, etc., according to this spec. With this system in place, I could look at my hardware support package manager and see Generic Bluetooth module, HP Printers, etc., and just untick them to uninstall the cruft that I don't have any use for. (As a side thought, I'm not sure what constitutes common hardware, but I for one don't know a single person who owns a Palm device.) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Standardised Hardware Support Spec - Please Review
This comes about as more and more people question why their computer starts bluetooth services when they don't have a bluetooth device, or why I have a HP printer driver control panel applet, or a Palm Pilot sync applet, or PCMCIA services, etc. etc. etc... https://wiki.ubuntu.com/StandardisedHardwareSupport Please let me know what to do next. Thanks! -- Alex Jones http://alex.weej.com/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
