Hello everyone.
We've recently started working on a project called Linux Hardware Compatibility Project or in short LHCP. Goals are:
* Provide a list of working hardware for people wanting to buy a new computer * Provide an idea on what hardware our/your distribution in run on * Provide a list of hardware we need to improve support for * Provide an interface to all above that allows simple and complicated queries * Get the user a list of thing that should work and a way to test that * Tell the user how good his hardware is supported
There have been several Hardware Compatibility lists from vendors and other projects in the past, but most of them were limited in one aspect or another - so we start our own.
To achive this we are building a modular framework to generate, collect, submit and analyze information about all components of systems running Linux and how well each component works.
The project is currently in it's infancy, but following the typical pragmatic approach of open source projects ("Release early, release often!") we've decided to already officially announce it.
Current status is that the basic GUI application for testing is up and running with some test modules. We're now in the process of writing the first real data collection and test modules and are currently starting to design the server end of the side.
The home page of the project can be found here:
https://hosted.fedoraproject.org/projects/LHCP
If you want to take a look at the current source code you can checked it out using Mercurial in read only mode like this:
hg clone http://hg.fedoraproject.org/hg/hosted/LHCP
For development discussions a mailing list has been set up here:
https://www.redhat.com/mailman/listinfo/lhcp-devel
Although the project is hosted under Fedora we're aiming it to be very distribution independant, so supporting other distributions should be easy to do. We have some basic requirements on what is needed on the system for it to simply work, but a lot of things will be optional.
Happy hacking,
Read ya, Phil & Fabi
Am Montag, den 29.01.2007, 16:24 +0100 schrieb Phil Knirsch:
Hello everyone.
We've recently started working on a project called Linux Hardware Compatibility Project or in short LHCP. Goals are:
- Provide a list of working hardware for people wanting to buy a new
computer
- Provide an idea on what hardware our/your distribution in run on
- Provide a list of hardware we need to improve support for
- Provide an interface to all above that allows simple and complicated
queries
- Get the user a list of thing that should work and a way to test that
- Tell the user how good his hardware is supported
There have been several Hardware Compatibility lists from vendors and other projects in the past, but most of them were limited in one aspect or another - so we start our own.
To achive this we are building a modular framework to generate, collect, submit and analyze information about all components of systems running Linux and how well each component works.
The project is currently in it's infancy, but following the typical pragmatic approach of open source projects ("Release early, release often!") we've decided to already officially announce it.
Current status is that the basic GUI application for testing is up and running with some test modules. We're now in the process of writing the first real data collection and test modules and are currently starting to design the server end of the side.
The home page of the project can be found here:
https://hosted.fedoraproject.org/projects/LHCP
If you want to take a look at the current source code you can checked it out using Mercurial in read only mode like this:
hg clone http://hg.fedoraproject.org/hg/hosted/LHCP
For development discussions a mailing list has been set up here:
https://www.redhat.com/mailman/listinfo/lhcp-devel
Although the project is hosted under Fedora we're aiming it to be very distribution independant, so supporting other distributions should be easy to do. We have some basic requirements on what is needed on the system for it to simply work, but a lot of things will be optional.
Happy hacking,
Read ya, Phil & Fabi
-- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch phil@redhat.de Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me.
Looks good. Will this enable a user to link to a specific piece of hardware for bugzilla reporting?
Any chance of a yum repo for easy updates (and more likely-to-test ness)?
(Dark and dusty weather?)
nodata wrote:
Am Montag, den 29.01.2007, 16:24 +0100 schrieb Phil Knirsch:
Hello everyone.
We've recently started working on a project called Linux Hardware Compatibility Project or in short LHCP. Goals are:
- Provide a list of working hardware for people wanting to buy a new
computer
- Provide an idea on what hardware our/your distribution in run on
- Provide a list of hardware we need to improve support for
- Provide an interface to all above that allows simple and complicated
queries
- Get the user a list of thing that should work and a way to test that
- Tell the user how good his hardware is supported
There have been several Hardware Compatibility lists from vendors and other projects in the past, but most of them were limited in one aspect or another - so we start our own.
To achive this we are building a modular framework to generate, collect, submit and analyze information about all components of systems running Linux and how well each component works.
The project is currently in it's infancy, but following the typical pragmatic approach of open source projects ("Release early, release often!") we've decided to already officially announce it.
Current status is that the basic GUI application for testing is up and running with some test modules. We're now in the process of writing the first real data collection and test modules and are currently starting to design the server end of the side.
The home page of the project can be found here:
https://hosted.fedoraproject.org/projects/LHCP
If you want to take a look at the current source code you can checked it out using Mercurial in read only mode like this:
hg clone http://hg.fedoraproject.org/hg/hosted/LHCP
For development discussions a mailing list has been set up here:
https://www.redhat.com/mailman/listinfo/lhcp-devel
Although the project is hosted under Fedora we're aiming it to be very distribution independant, so supporting other distributions should be easy to do. We have some basic requirements on what is needed on the system for it to simply work, but a lot of things will be optional.
Happy hacking,
Read ya, Phil & Fabi
-- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch phil@redhat.de Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me.
Looks good. Will this enable a user to link to a specific piece of hardware for bugzilla reporting?
Good point, we'll add that to feature list.
Any chance of a yum repo for easy updates (and more likely-to-test ness)?
Yea, as soon as we're done with the server side as well we'll be doing some "real" packaging of the whole project with specfile and autoFOO magic.
(Dark and dusty weather?)
Weather sucked here during the last few weeks so this looked like the perfect test module. :)
Read ya, Phil
PS: Don't mention the rocket :)
On Mon, 2007-01-29 at 16:24 +0100, Phil Knirsch wrote:
Hello everyone.
We've recently started working on a project called Linux Hardware Compatibility Project or in short LHCP. Goals are:
Just a nit, but nomenclature for sleep states should probably be consistent with the rest of the desktop.
Suspend-to-disk should probably be "hibernate" and suspend-to-ram should be "suspend". The reverse action is "resume from suspend" for example.
See http://svn.gnome.org/svn/gnome-power-manager/trunk/docs/sleep-names.html for rationale.
Richard.
Richard Hughes wrote:
On Mon, 2007-01-29 at 16:24 +0100, Phil Knirsch wrote:
Hello everyone.
We've recently started working on a project called Linux Hardware Compatibility Project or in short LHCP. Goals are:
Just a nit, but nomenclature for sleep states should probably be consistent with the rest of the desktop.
Suspend-to-disk should probably be "hibernate" and suspend-to-ram should be "suspend". The reverse action is "resume from suspend" for example.
See http://svn.gnome.org/svn/gnome-power-manager/trunk/docs/sleep-names.html for rationale.
Richard.
Thanks Richard, i'll change the nomenclature accordingly.
Read ya, Phil
hughsient@gmail.com (Richard Hughes) writes:
Suspend-to-disk should probably be "hibernate" and suspend-to-ram should be "suspend".
I do not think so. I can not imagine what 'hibernate' means or which components are affected by 'suspend'.
'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state).
Enrico
On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote:
'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state).
And how many joe-average Linux users know what the contents of /sys/power/state is? Also, my girlfriend has no concept of what "ram" is, and why it should be faster than "disk".
She does understand the speed difference between suspend and hibernate.
I really don't think it's important to know what each of the Sx states is doing to individual bits of hardware, not for the end user anyway.
Richard.
"RH" == Richard Hughes hughsient@gmail.com writes:
RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote:
'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state).
RH> And how many joe-average Linux users know what the contents of RH> /sys/power/state is? Also, my girlfriend has no concept of what RH> "ram" is, and why it should be faster than "disk".
RH> She does understand the speed difference between suspend and RH> hibernate.
I don't think I'll ever be able to remember which of suspend and hibernate means suspend-to-disk. Perhaps its easier for native English speakers, or perhaps I need my brain fixed.
/Benny
Benny Amorsen wrote:
"RH" == Richard Hughes hughsient@gmail.com writes:
RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote:
'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state).
RH> And how many joe-average Linux users know what the contents of RH> /sys/power/state is? Also, my girlfriend has no concept of what RH> "ram" is, and why it should be faster than "disk".
RH> She does understand the speed difference between suspend and RH> hibernate.
I don't think I'll ever be able to remember which of suspend and hibernate means suspend-to-disk. Perhaps its easier for native English speakers, or perhaps I need my brain fixed.
Then use the English dictionary to learn that hibernate is what some animals, e.g. bears as a long sleep over the winter, thus is considered a longer sleep.
Or, use a mnemonic device of some sort to help. For example, spell them out:
Suspend <-- shorter (less letters) Hibernate <-- longer (more letters)
Suspend takes the shorter time, and is RAM, and hibernate takes longer to do, thus suspend to disk.
tor, 01 02 2007 kl. 10:07 -0500, skrev Christopher Aillon:
Benny Amorsen wrote:
> "RH" == Richard Hughes hughsient@gmail.com writes:
RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote:
'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state).
RH> And how many joe-average Linux users know what the contents of RH> /sys/power/state is? Also, my girlfriend has no concept of what RH> "ram" is, and why it should be faster than "disk".
RH> She does understand the speed difference between suspend and RH> hibernate.
I don't think I'll ever be able to remember which of suspend and hibernate means suspend-to-disk. Perhaps its easier for native English speakers, or perhaps I need my brain fixed.
Then use the English dictionary to learn that hibernate is what some animals, e.g. bears as a long sleep over the winter, thus is considered a longer sleep.
Or, use a mnemonic device of some sort to help. For example, spell them out:
Suspend <-- shorter (less letters) Hibernate <-- longer (more letters)
Suspend takes the shorter time, and is RAM, and hibernate takes longer to do, thus suspend to disk.
A problem you are overlooking is that the whole suspend, hibernate, sleep thing doesn't translate well at all. I had the (dis)pleasure of translating gnome-power-manager and you end up trying to convey slight technical differences in languages which sometimes don't have direct equivalents..
- David Nielsen
On Thu, 2007-02-01 at 18:39 +0100, David Nielsen wrote:
A problem you are overlooking is that the whole suspend, hibernate, sleep thing doesn't translate well at all. I had the (dis)pleasure of translating gnome-power-manager and you end up trying to convey slight technical differences in languages which sometimes don't have direct equivalents..
So you choose non-English words that convey the sleep state, for instance "nap" and "slumber" are two alternate words you could have used in English. I really don't think choosing non-native wording is a good excuse for expressing detailed device specification in the UI. The language teams just have to choose two words in a locale and stick to it.
I can even add a translation section to the nomenclature page if you like.
Richard.
tor, 01 02 2007 kl. 18:02 +0000, skrev Richard Hughes:
On Thu, 2007-02-01 at 18:39 +0100, David Nielsen wrote:
A problem you are overlooking is that the whole suspend, hibernate, sleep thing doesn't translate well at all. I had the (dis)pleasure of translating gnome-power-manager and you end up trying to convey slight technical differences in languages which sometimes don't have direct equivalents..
So you choose non-English words that convey the sleep state, for instance "nap" and "slumber" are two alternate words you could have used in English. I really don't think choosing non-native wording is a good excuse for expressing detailed device specification in the UI. The language teams just have to choose two words in a locale and stick to it.
I can even add a translation section to the nomenclature page if you like.
I wasn't picking on you Richard but I'm sure translators will take any help they can get though.
I see no big functional difference between the two, might it not be possible just to have one suspend function based on what works best for the platform and having the other (be that STR or STD) be available say via a gconf key. I assume we could catch botched resumes and inform the user that say STR would no longer be the default as it appears unsupported currently. This way we'd have fewer options and the same level of functionality. I suppose LHCP long term will be helpful in tracking down broken drivers (Matthew Garrett claims to drink heavily due to driver suspend/resume bugs - let's save Matthew' poor liver).
Do I need to put down the crack pipe?
- David
On Thu, 2007-02-01 at 19:44 +0100, David Nielsen wrote:
I wasn't picking on you Richard but I'm sure translators will take any help they can get though.
Sure, I'll blog about the suspend hibernate nomenclature for translators and see if we can get a pseudo-standard sorted for all locales.
See http://live.gnome.org/GnomePowerManager/SleepNames for the list so far.
Do I need to put down the crack pipe?
Whilst I understand the simplification for users argument, I think suspend (computer still "on", takes about 10 seconds) and hibernate (computer "off", takes about a minute and a half) are sufficiently different to give the user a choice if they have both working.
g-p-m already just modifies it's preferences automatically if only one, or neither "should" work on the system.
Richard.
On 2/1/07, Richard Hughes hughsient@gmail.com wrote:
On Thu, 2007-02-01 at 19:44 +0100, David Nielsen wrote:
I wasn't picking on you Richard but I'm sure translators will take any help they can get though.
Sure, I'll blog about the suspend hibernate nomenclature for translators and see if we can get a pseudo-standard sorted for all locales.
See http://live.gnome.org/GnomePowerManager/SleepNames for the list so far.
Nice page. I'd argue the italian for Resume is definetely not Resume: shoud probably be Riprendi (spanish like) or Riattiva (french like).
/me just wonders why french is the only language with a complete sentence for the action, much like "put to sleep", "put to hibernation"...
On 2/1/07, Richard Hughes hughsient@gmail.com wrote:
On Thu, 2007-02-01 at 22:50 +0100, Gianluca Sforna wrote:
Nice page. I'd argue the italian for Resume is definetely not Resume: shoud probably be Riprendi (spanish like) or Riattiva (french like).
Please could you choose one and edit the wiki accordingly.
Done
Gianluca Sforna wrote:
On 2/1/07, Richard Hughes hughsient@gmail.com wrote:
On Thu, 2007-02-01 at 22:50 +0100, Gianluca Sforna wrote:
Nice page. I'd argue the italian for Resume is definetely not Resume: shoud probably be Riprendi (spanish like) or Riattiva (french like).
Please could you choose one and edit the wiki accordingly.
Done
"Bereitschaft" for the german translations means "readiness" not anything sleep related.
Benny Amorsen wrote:
"RH" == Richard Hughes hughsient@gmail.com writes:
RH> On Thu, 2007-02-01 at 01:21 +0100, Enrico Scholz wrote:
'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state).
RH> And how many joe-average Linux users know what the contents of RH> /sys/power/state is? Also, my girlfriend has no concept of what RH> "ram" is, and why it should be faster than "disk".
RH> She does understand the speed difference between suspend and RH> hibernate.
I don't think I'll ever be able to remember which of suspend and hibernate means suspend-to-disk. Perhaps its easier for native English speakers, or perhaps I need my brain fixed.
/Benny
Hm, i've talked also with a few other folks here and maybe a short description would help a lot. Or do something like:
Hibernate (suspend to memory)
and
Suspend (suspend to harddisk)
although the later really looks wierd as suspend is used twice there. I'll try a few things and see what looks best, probably dicing up the description.
Read ya, Phil
Hi Phil,
On Thu, 2007-02-01 at 16:47 +0100, Phil Knirsch wrote:
Hm, i've talked also with a few other folks here and maybe a short description would help a lot. Or do something like:
Hibernate (suspend to memory)
and
Suspend (suspend to harddisk)
It's exactly vice versa ;-). At least here on my Desktop(tm)(*), "Hibernate" suspends to disk and the "Suspend" entry of the power manager applet has a nice stylized memory module overlay (though I haven't tried it out lately as I should have).
(*): Given some not quite recent discussions on this list, my not mentioning what desktop environment I'm using should give you an idea what I use. Sort of ;-P.
although the later really looks wierd as suspend is used twice there. I'll try a few things and see what looks best, probably dicing up the description.
Maybe:
Hibernate (to disk)
and:
Suspend (to memory)
Ciao, Nils
On Fri, 2007-02-02 at 16:19 +0100, Till Maas wrote:
hibernate (suspend to disk) sleep (suspend to ram)
No, sleep is used and has been used for all the sleep states over the years, S1, S3 *and* S4. It's got no real meaning anymore.
If talking about situations involving suspend and hibernate, sleep if okay as it means both, and in this case I think it's harmless.
Richard.
hughsient@gmail.com (Richard Hughes) writes:
'suspend-to-disk' and 'suspend-to-ram' are much more descriptives names and more consistent with rest of system (/sys/power/state).
And how many joe-average Linux users know what the contents of /sys/power/state is? Also, my girlfriend has no concept of what "ram" is, and why it should be faster than "disk".
Then, she should not be part of the LHCP userbase. Reports from people who do not know the difference between ram and disk are useless and would generate wrong entries in the hardware database only.
Enrico
Hi all!
Phil Knirsch schrieb:
We've recently started working on a project called Linux Hardware Compatibility Project or in short LHCP.
Nice. But well: It sound like yet-another-hardware-compatibility-list to me. Thus I'm wondering: Don't we have enough of those already? You link to several yourself on https://hosted.fedoraproject.org/projects/LHCP/wiki/Links So why yet another approach? Why not co-operate with one of those? Or wait, let's do it even better: Try to work together with all of those those and solve the problem once and for all *properly* and in a general way? Read that as: cooperate with at least Novell/Opensuse, Debian and Ubuntu and maybe get OSDL ^w TLF on board (from the start of).
[...] There have been several Hardware Compatibility lists from vendors and other projects in the past, but most of them were limited in one aspect or another - so we start our own.
Is that reason really good enough? And how do you make sure your approach is not "limited in one aspect or another" in the end, too? If so many other projects did it wrong I'd say this effort will either need a lot of work and manpower or it will run into similar problems.
[...] Although the project is hosted under Fedora we're aiming it to be very distribution independant, so supporting other distributions should be easy to do.
Why don't we get then on the board *from the start* of?
[...]
CU thl
Thorsten Leemhuis wrote:
Nice. But well: It sound like yet-another-hardware-compatibility-list to me. Thus I'm wondering: Don't we have enough of those already?
Agreed.
Or wait, let's do it even better: Try to work together with all of those those and solve the problem once and for all *properly* and in a general way? Read that as: cooperate with at least Novell/Opensuse, Debian and Ubuntu and maybe get OSDL ^w TLF on board (from the start of).
That would be awesome. So many people are waiting for such a list.
How about something linked with Smolt ? You report your hardware with Smolt, it takes you to a webpage where you have a table with all your hardware, and 3 checkboxes for each component : Works, Works partially, Does not work.
If that sounds good, Smolt could then be ported to other distros, and the results of each could be aggregated on a single authoritative website.
I for one would love to see something like that.
Aurélien
On 30.01.2007 18:22, Thorsten Leemhuis wrote:
Phil Knirsch schrieb:
We've recently started working on a project called Linux Hardware Compatibility Project or in short LHCP.
Nice. But well: It sound like yet-another-hardware-compatibility-list to me. Thus I'm wondering: Don't we have enough of those already? You link to several yourself on https://hosted.fedoraproject.org/projects/LHCP/wiki/Links So why yet another approach? Why not co-operate with one of those? Or wait, let's do it even better: Try to work together with all of those those and solve the problem once and for all *properly* and in a general way? Read that as: cooperate with at least Novell/Opensuse, Debian and Ubuntu and maybe get OSDL ^w TLF on board (from the start of). [...]
Seems I didn't get much replies on this besides the post from Aurelien. :-(
Anyway, there is yet a new effort out there that tries to solve the "is my hardware compatible to my operating system/linux" problem. And it not even tries to be cross-distribution, it tries it to solve it this problem for all major Operating Systems: http://www.compatdb.org/
[...] The CompatDB.org project is an attempt to create a free (as in the freedom) standard for user submitted compatibility lists as well free compatibility lists for Windows, Linux, and Mac OS. [...] The following operating systems are currently supported by CompatDB.org: [...] Linux: [...] Fedora Core [...] [...]
CU thl
-
Aurelien Bompard -
Benny Amorsen -
Christopher Aillon -
David Nielsen -
drago01 -
Enrico Scholz -
Gianluca Sforna -
Nils Philippsen -
nodata -
Phil Knirsch -
Richard Hughes -
Thorsten Leemhuis -
Till Maas