[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-hardware-devel
Subject: Re: [Kde-hardware-devel] KDE (Linux hardware) issues
From: Christopher Blauvelt <cblauvelt () gmail ! com>
Date: 2006-01-08 19:21:03
Message-ID: ffa898c90601081121m1b52d2ecv4f376d8328a33a () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
It seems that the first priority of solid should be informational. The
device manager that you're describing would be better suited as a "helper
application." Or a front end that is capable of accessing the knowledge
base and downloading and/or compiling drivers as needed. This would be in
keeping with the tried and true *nix mantra of do one thing really well. A
device manager would be an appropriate application to be released with
kde4. It all depends on how ambitious we're willing to be.
I believe your second point is very valid. Mostly as a courtesy to the use=
r
more or less to update that system so it knows what's installed and what
isn't. This again would be a priority of the device manager application.
I don't really understand what you're getting at in your third point.
Transferring hard drives to another system?
A live CD needs to be a future goal of the project. I, however, see a very
limited use for it. Most of what the knowledge base is all about is what
driver combination to use to get a device working "as advertised." That
takes trial and error and usually some google'ing. Most of my time spend
getting devices to work is not spent coding. In fact, I don't believe my
coding knowledge really helps me at all.
Judging by the pace of previous KDE system development I feel that having
narrowly focused goals and sticking to them will make the biggest
contribution to KDE and foster the greatest amount of adoption.
Well that's what I think. Feel free to disagree.
Chris
On 1/8/06, Alexander Antoniades <sanderant@gmail.com> wrote:
>
> Hi all, you asked for input so I thought I'd put in my 0.02$ as requested
> on
> the announcement. I'd just like to put out a couple of ideas/questions on
> the
> offhand chance you haven't thought of them (doubtful, but you never know)=
.
> :)
>
> 1) The biggest problem with most of the hardware interaction issues with
> Linux
> is that projects like HAL Device Manager is that they offer information,
> but
> no way to rectify the problem. I know that Hal Device Manager was made
> that
> way by design, but this makes it relatively useless, so the first issue i=
s
> I
> hope any type of device manager style applications provide a way to
> actually
> change or rectify hardware problems as opposed to simply stating what the
> system sees.
> From my experience having to deal with that OS that runs on 90% of the
> worlds
> computers everyday, the main use of a device manager style application is
> to
> see if the OS sees the right hardware and to sometimes change drivers in
> the
> case of mis-identification, or drop to a generic driver in the case of a
> driver not working correctly.
> This is my main shortcoming with Linux these days and would go a long way
> to
> help those of us who try to evangelize and expand Linux's base.
>
> 2) What about integration with any existing projects? In particular I was
> thinking about Ubuntu's hardware database and YaST. I know YaST is a whol=
e
> backend, but components like SAX2 are GPL and seem like they would go a
> long
> way towards making X (which I assume would be a necessary prerequisite to
> KDE
> on all platforms) easier to manage.
>
> 3) One more wish (which isn't done by any OS I know of) would be the
> ability
> to show all the drivers the currently installed KDE system. This would
> help
> for in the event of moving the hard drive to another system or switching
> out
> hardware the ability to anticipate the difficulty of any change or when
> making upgrade decisions.
>
> 4) Lastly, for those of us that don't have programming skills, but have
> access
> to a wide array of hardware I would suggest you plan on releasing live CD=
s
> to
> help us assist in any hardware information gathering as I'm sure you'll
> get
> as much information as you can handle that way.
>
> I realize these are generally pretty obvious, but I wanted to make sure I
> offered them up for you since the project is just starting.
>
> Thank you for addressing this weakness in KDE and I look forward to your
> progress!
>
> Sander
> _______________________________________________
> Kde-hardware-devel mailing list
> Kde-hardware-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-hardware-devel
>
[Attachment #5 (text/html)]
<div>It seems that the first priority of solid should be informational. The \
device manager that you're describing would be better suited as a "helper \
application." Or a front end that is capable of accessing the knowledge \
base and downloading and/or compiling drivers as needed. This would be in \
keeping with the tried and true *nix mantra of do one thing really well. A \
device manager would be an appropriate application to be released with kde4. It \
all depends on how ambitious we're willing to be. </div>
<div>I believe your second point is very valid. Mostly as a courtesy to the \
user more or less to update that system so it knows what's installed and what \
isn't. This again would be a priority of the device manager application. \
</div> <div>I don't really understand what you're getting at in your third \
point. Transferring hard drives to another system?</div> <div>A live CD needs \
to be a future goal of the project. I, however, see a very limited use for \
it. Most of what the knowledge base is all about is what driver combination to \
use to get a device working "as advertised." That takes trial and \
error and usually some google'ing. Most of my time spend getting devices to \
work is not spent coding. In fact, I don't believe my coding knowledge really \
helps me at all. </div>
<div>Judging by the pace of previous KDE system development I feel that having \
narrowly focused goals and sticking to them will make the biggest contribution to KDE \
and foster the greatest amount of adoption.</div> <div>Well that's what I \
think. Feel free to disagree.</div> <div>Chris<br> </div><br><br>
<div><span class="gmail_quote">On 1/8/06, <b class="gmail_sendername">Alexander \
Antoniades</b> <<a href="mailto:sanderant@gmail.com">sanderant@gmail.com</a>> \
wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px \
0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi all, you asked for input so I thought \
I'd put in my 0.02$ as requested on<br>the announcement. I'd just like to put out a \
couple of ideas/questions on the <br>offhand chance you haven't thought of them \
(doubtful, but you never know). :)<br><br>1) The biggest problem with most of the \
hardware interaction issues with Linux<br>is that projects like HAL Device Manager is \
that they offer information, but <br>no way to rectify the problem. I know that Hal \
Device Manager was made that<br>way by design, but this makes it relatively useless, \
so the first issue is I<br>hope any type of device manager style applications provide \
a way to actually <br>change or rectify hardware problems as opposed to simply \
stating what the<br>system sees.<br>From my experience having to deal with that OS \
that runs on 90% of the worlds<br>computers everyday, the main use of a device \
manager style application is to <br>see if the OS sees the right hardware and to \
sometimes change drivers in the<br>case of mis-identification, or drop to a generic \
driver in the case of a<br>driver not working correctly.<br>This is my main \
shortcoming with Linux these days and would go a long way to <br>help those of us who \
try to evangelize and expand Linux's base.<br><br>2) What about integration with any \
existing projects? In particular I was<br>thinking about Ubuntu's hardware database \
and YaST. I know YaST is a whole <br>backend, but components like SAX2 are GPL and \
seem like they would go a long<br>way towards making X (which I assume would be a \
necessary prerequisite to KDE<br>on all platforms) easier to manage.<br><br>3) One \
more wish (which isn't done by any OS I know of) would be the ability <br>to show all \
the drivers the currently installed KDE system. This would help<br>for in the event \
of moving the hard drive to another system or switching out<br>hardware the ability \
to anticipate the difficulty of any change or when <br>making upgrade \
decisions.<br><br>4) Lastly, for those of us that don't have programming skills, but \
have access<br>to a wide array of hardware I would suggest you plan on releasing live \
CDs to<br>help us assist in any hardware information gathering as I'm sure you'll get \
<br>as much information as you can handle that way.<br><br>I realize these are \
generally pretty obvious, but I wanted to make sure I<br>offered them up for you \
since the project is just starting.<br><br>Thank you for addressing this weakness in \
KDE and I look forward to your \
<br>progress!<br><br>Sander<br>_______________________________________________<br>Kde-hardware-devel \
mailing list<br><a href="mailto:Kde-hardware-devel@kde.org">Kde-hardware-devel@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/kde-hardware-devel"> \
https://mail.kde.org/mailman/listinfo/kde-hardware-devel</a><br></blockquote></div><br>
_______________________________________________
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic