4:27 p.m.
I was working on finding/reporting some bugs with the hplip package and
noticed that there was no menu entry. Knowing that a graphical program
with no menu entry wasn't the norm, I was about to file a bug, except
when searching for a duplicate, I came across this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762
mclasen(a)redhat.com:
"We don't give free ad space to HP on our menus..."
I find that to be both an interesting and hypocritical comment. Please
someone tell me how:
1) HP provides free GPL software for controlling and printing with their
printers. 100% opensource. Yet we remove the menu entry because that
would be advertising. (And when I say 100% opensource, I mean there is
code, not a binary firmware blob or such b.s.)
2) RealVNC is a company that has a product called VNC. They provide a
opensource version of the product that is included in fedora. This
program gets free "advertising space" on the menu including the VNC
logo, which AFAICS is identical to the company logo except the word "REAL".
3) And the in F7, there will be CodecBuddy
(http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy) which will
direct users to the Fluendo Webshop (https://shop.fluendo.com/) to
purchase proprietary codes when they try to play media that they do not
have a code for (http://hadessuk.blogspot.com/2007/03/totem-news.html).
Hey, I'm all for these type of convenience settings, but fair is fair,
but the hplip: hp-toolbox menu item back on the system menu.
4:39 p.m.
On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762
mclasen(a)redhat.com:
"We don't give free ad space to HP on our menus..."
I find that to be both an interesting and hypocritical comment.
FWIW, the comment was referring to the HP icon in the menus.
5:13 p.m.
Matthias Clasen wrote:
On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote:
> mclasen(a)redhat.com:
> "We don't give free ad space to HP on our menus..."
>
>
> I find that to be both an interesting and hypocritical comment.
FWIW, the comment was referring to the HP icon in the menus.
That was my assumption, but I could have read it any number of other
ways as well.
Do you still feel the same way given the other examples that I posted?
5:36 p.m.
On Mon, 2007-03-26 at 16:13 -0600, Bernard Johnson wrote:
Matthias Clasen wrote:
> On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote:
>> mclasen(a)redhat.com:
>> "We don't give free ad space to HP on our menus..."
>>
>>
>> I find that to be both an interesting and hypocritical comment.
>
> FWIW, the comment was referring to the HP icon in the menus.
>
That was my assumption, but I could have read it any number of other
ways as well.
Do you still feel the same way given the other examples that I posted?
David outlined a number of reasons why the hplip stack is really less
than ideal from a desktop integration perspective. So yes, I still think
that hplip and assorted gui tools are not the solution we want and do
not really move us closer to the goal of making printing suck less.
Matthias
PS And no, I did not do an exhaustive search through all the menus
before making the comment about the icon. If the VNC icon is just a
company icon in disguise, the same comment applies there too.
5:38 p.m.
On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote:
PS And no, I did not do an exhaustive search through all the menus
before making the comment about the icon. If the VNC icon is just a
company icon in disguise, the same comment applies there too.
If it's about the icon, I can put a different icon in there if you like.
Tim.
*/
5:49 p.m.
On Mon, 2007-03-26 at 23:38 +0100, Tim Waugh wrote:
On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote:
> PS And no, I did not do an exhaustive search through all the menus
> before making the comment about the icon. If the VNC icon is just a
> company icon in disguise, the same comment applies there too.
If it's about the icon, I can put a different icon in there if you like.
No, it is not just about the icon. David gave a somewhat ranty summary
of the issues further up in this thread...
8:56 p.m.
Matthias Clasen wrote:
On Mon, 2007-03-26 at 23:38 +0100, Tim Waugh wrote:
> On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote:
>> PS And no, I did not do an exhaustive search through all the menus
>> before making the comment about the icon. If the VNC icon is just a
>> company icon in disguise, the same comment applies there too.
> If it's about the icon, I can put a different icon in there if you like.
>
No, it is not just about the icon. David gave a somewhat ranty summary
of the issues further up in this thread...
I read this as "so the software suck, let's not add an icon so the users
of that software can get to it easily".
Which, btw, is fine with me, as I have the 2.5 braincells needed to find
it. However, with an attitude like this, the "Fedora on the desktop"
idea is a fallacy as long as standard
Scenario #1
User: "When I click on a .mp3 file, I get an error, why doesn't this work"
Reason: It's not legal to distribute mp3 codecs.
Acceptable?: What other choice do we have? (yes CodeBuddy is being
worked on but it's not a reality yet)
Scenario #2
User: "I could fax/get status/copy with my HP xxx printer in Windows but
in Linux it only prints"
Reason: We have a vendetta against HP and refuse to put the icon on the
menu because in our eyes the software sucks (although it does work).
[therefore user has to learn commands like rpm -ql package to find out
what is available]
Acceptable?: ? I don't think so, but it certainly looks like I'm in the
minority.
Seriously, you want me to list everything about Fedora that sucks yet
gets a place on the menu?
No, probably not.
Level the playing field, everyone will benefit.
9 p.m.
Matthias Clasen wrote:
On Mon, 2007-03-26 at 23:38 +0100, Tim Waugh wrote:
> On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote:
>> PS And no, I did not do an exhaustive search through all the menus
>> before making the comment about the icon. If the VNC icon is just a
>> company icon in disguise, the same comment applies there too.
> If it's about the icon, I can put a different icon in there if you like.
>
No, it is not just about the icon. David gave a somewhat ranty summary
of the issues further up in this thread...
If you can not be persuaded to allow the hp toolbox icon, please change
the buzilla report to at least represent the actual cause of removing
the desktop icon.
9:03 p.m.
Matthias Clasen wrote:
PS And no, I did not do an exhaustive search through all the menus
before making the comment about the icon. If the VNC icon is just a
company icon in disguise, the same comment applies there too.
So would you also say that you are against gstreamer based software
directing users towards the Fluendo webshop?
That's not just advertising, it's sole-sourcing.
(For the record, I'm not against this at all, as long as all vendors
have the same access)
3:38 a.m.
On 3/26/07, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Mon, 2007-03-26 at 16:13 -0600, Bernard Johnson wrote:
> Matthias Clasen wrote:
> > On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote:
> >> mclasen(a)redhat.com:
> >> "We don't give free ad space to HP on our menus..."
> >>
> >>
> >> I find that to be both an interesting and hypocritical comment.
> >
> > FWIW, the comment was referring to the HP icon in the menus.
> >
>
> That was my assumption, but I could have read it any number of other
> ways as well.
>
> Do you still feel the same way given the other examples that I posted?
>
David outlined a number of reasons why the hplip stack is really less
than ideal from a desktop integration perspective. So yes, I still think
that hplip and assorted gui tools are not the solution we want and do
not really move us closer to the goal of making printing suck less.
Matthias
PS And no, I did not do an exhaustive search through all the menus
before making the comment about the icon. If the VNC icon is just a
company icon in disguise, the same comment applies there too.
wow wow wow,
I don't know about you guys, but I use the HPLIP stack. And I don't
know what is more user-friendly than having it all working "out of the
box". The only reason I haven't noticed the menu shortcuts were
missing is that it all works so well. Then again, maybe if they were
in there I would have noticed my ink was running low a lot earlier.
If the software meets Fedora's already strict legal requirements, then
it should be packaged like any other package. The reason given for not
including the shortcut is plain silly. Or at the very list, if that is
going to be a reason used, then all packages need to have generic
icons because the whole point of an icon to a program is recognition
and advertisement. HP wrote the stack, why can't their icon be used.
This is being overly nitpicky about things.
Peace.
--
Fedora Core 6 and proud
6:25 a.m.
Arthur Pemberton wrote:
On 3/26/07, Matthias Clasen <mclasen(a)redhat.com> wrote:
> On Mon, 2007-03-26 at 16:13 -0600, Bernard Johnson wrote:
> > Matthias Clasen wrote:
> > > On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote:
> > >> mclasen(a)redhat.com:
> > >> "We don't give free ad space to HP on our menus..."
> > >>
> > >>
> > >> I find that to be both an interesting and hypocritical comment.
> > >
> > > FWIW, the comment was referring to the HP icon in the menus.
> > >
> >
> > That was my assumption, but I could have read it any number of other
> > ways as well.
> >
> > Do you still feel the same way given the other examples that I posted?
> >
>
> David outlined a number of reasons why the hplip stack is really less
> than ideal from a desktop integration perspective. So yes, I still think
> that hplip and assorted gui tools are not the solution we want and do
> not really move us closer to the goal of making printing suck less.
>
> Matthias
>
> PS And no, I did not do an exhaustive search through all the menus
> before making the comment about the icon. If the VNC icon is just a
> company icon in disguise, the same comment applies there too.
>
wow wow wow,
I don't know about you guys, but I use the HPLIP stack. And I don't
know what is more user-friendly than having it all working "out of the
box". The only reason I haven't noticed the menu shortcuts were
missing is that it all works so well. Then again, maybe if they were
in there I would have noticed my ink was running low a lot earlier.
If the software meets Fedora's already strict legal requirements, then
it should be packaged like any other package. The reason given for not
including the shortcut is plain silly. Or at the very list, if that is
going to be a reason used, then all packages need to have generic
icons because the whole point of an icon to a program is recognition
and advertisement. HP wrote the stack, why can't their icon be used.
This is being overly nitpicky about things.
+1
Peace.
5 p.m.
On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote:
1) HP provides free GPL software for controlling and printing with
their
printers. 100% opensource. Yet we remove the menu entry because that
would be advertising. (And when I say 100% opensource, I mean there is
code, not a binary firmware blob or such b.s.)
Now, if only HP would play nicely with the open source community and
_just_ provide only drivers instead of reinventing the wheel by
- provide a system-wide daemon for handing device access; oh, how nice,
this completely bypasses OS security measures; for example, as a user
logged in via SSH I can access the scanner. I should actually file
that as a security bug. Bad.
- Oh, and it's hard to actually change this; it's not like HPLip
provides an easy to read list of what devices should get changed
to provide access to the console user. To e.g. generate udev rules
or HAL fdi files. Bad.
- Not only that; starting this daemon is completely useless unless you
have HP hardware. We still start it for everyone so everyone have
to suffer. That's bad.
- Provide their own UI for using the device; just provide the drivers,
thank you very much; we don't really need foreign tools to make this
harder on the users. Bad.
- Try reading the HPLip sources; they provide access to the card reader
by using a user-space vfat driver! Oh yeah!
- All the HP stuff, since there is a lot of it, pulls in Qt which is
not desirable for e.g. live CD. For example, Jeremy just pulled hplip
from the test3 live cd because it wouldn't fit [1]. Also python
is pulled in although this is less controversial. Good stuff that
OLPC is based on Python otherwise they would have a hard time
using the HP drivers.
Instead, for example, HP should get their scanner drivers into the SANE
project. My personal opinion is that with HPLip, HP is paying lip
service to the Linux community by treating us as if we were Windows
where this sort of "let's throw lots of vendor-specific tools and UI
crap at the user" is common.
HP: please try to be a good open source citizen. Give us drivers and
drivers only. We're not really interested in end-user programs that uses
libusb/vfat user space drivers for example. If you really want to
contribute to the UI, please start supporting the efforts going on in
the GNOME and KDE communities - for example GnomeScan could use more
help. Many thanks.
Btw, I'd love to be proven wrong and that one can actually build HPLip
so only drivers and no silly privilege-escalation system-wide daemon is
used. Hey, it's GPL, perhaps someone can just fork it until HP starts
getting it.
David
[1] :
http://git.fedoraproject.org/?p=hosted/livecd;a=commitdiff;h=ac05753140cf...
5:03 p.m.
(It's most probably this is needless to say, but these are my own points
of view and does not necessarily reflect those of my employer which is
Red Hat, Inc.).
On Mon, 2007-03-26 at 18:00 -0400, David Zeuthen wrote:
On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote:
> 1) HP provides free GPL software for controlling and printing with their
> printers. 100% opensource. Yet we remove the menu entry because that
> would be advertising. (And when I say 100% opensource, I mean there is
> code, not a binary firmware blob or such b.s.)
Now, if only HP would play nicely with the open source community and
_just_ provide only drivers instead of reinventing the wheel by
- provide a system-wide daemon for handing device access; oh, how nice,
this completely bypasses OS security measures; for example, as a user
logged in via SSH I can access the scanner. I should actually file
that as a security bug. Bad.
- Oh, and it's hard to actually change this; it's not like HPLip
provides an easy to read list of what devices should get changed
to provide access to the console user. To e.g. generate udev rules
or HAL fdi files. Bad.
- Not only that; starting this daemon is completely useless unless you
have HP hardware. We still start it for everyone so everyone have
to suffer. That's bad.
- Provide their own UI for using the device; just provide the drivers,
thank you very much; we don't really need foreign tools to make this
harder on the users. Bad.
- Try reading the HPLip sources; they provide access to the card reader
by using a user-space vfat driver! Oh yeah!
- All the HP stuff, since there is a lot of it, pulls in Qt which is
not desirable for e.g. live CD. For example, Jeremy just pulled hplip
from the test3 live cd because it wouldn't fit [1]. Also python
is pulled in although this is less controversial. Good stuff that
OLPC is based on Python otherwise they would have a hard time
using the HP drivers.
Instead, for example, HP should get their scanner drivers into the SANE
project. My personal opinion is that with HPLip, HP is paying lip
service to the Linux community by treating us as if we were Windows
where this sort of "let's throw lots of vendor-specific tools and UI
crap at the user" is common.
HP: please try to be a good open source citizen. Give us drivers and
drivers only. We're not really interested in end-user programs that uses
libusb/vfat user space drivers for example. If you really want to
contribute to the UI, please start supporting the efforts going on in
the GNOME and KDE communities - for example GnomeScan could use more
help. Many thanks.
Btw, I'd love to be proven wrong and that one can actually build HPLip
so only drivers and no silly privilege-escalation system-wide daemon is
used. Hey, it's GPL, perhaps someone can just fork it until HP starts
getting it.
David
[1] :
http://git.fedoraproject.org/?p=hosted/livecd;a=commitdiff;h=ac05753140cf...
8:56 p.m.
David Zeuthen wrote:
Now, if only HP would play nicely with the open source community and
_just_ provide only drivers instead of reinventing the wheel by
Well, I'm sure you're just emphatic about "better software" but I think
it comes across as looking a gift horse in the mouth. I mean, what do
you want, junk the hp software and then I can have the same printing
capabilities as when I had this:
http://openprinting.org/show_printer.cgi?recnum=HP-LaserJet_3100
Where are your bug reports to them? Your feature requests? Have you
even interacted with the hplip guys before?
- Not only that; starting this daemon is completely useless unless
you
have HP hardware. We still start it for everyone so everyone have
to suffer. That's bad.
and so is:
smartd when I don't have a smartd drive
bluethooth when I don't have bluetooth
etc
We have:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222312
Unfortunately, AFAICS, this bug will only solve that for connected
devices. What about devices like mine that are on the network? How do
you know when to start/stop services then? Are you suggesting that HP
upgrade all their printer firmwares with Rendezvous support?
It's what we have now [2].
- Provide their own UI for using the device; just provide the
drivers,
thank you very much; we don't really need foreign tools to make this
harder on the users. Bad.
Oh? You have tools that work with their printers? No. Their job is to
take care of their customers, which they are doing (even with Linux!) by
providing software that works. Every issues that I've reported to the
hplip guys has been dealt with in a timely manner (sans firmware issues
reported to another group). That's a helluva lot more than I can say
about reporting bugs to RedHat/Fedora [1].
We are lucky that they are much more business savvy regarding opensource
than the idiots running the lightscribe group. If you think hplip is
hard to swallow, download their lightscribe software and try not to
regurgitate.
And as far as complaining, bitching, moaning about HP not being "good
opensource citizens"...
How far as that gotten you with things like Broadcom wireless firmware?
Oh, you're still loading binary blobs. Gotcha.
It's nice to sit in your tower and throw rocks, but end then end, some
of us work with these products and are held accountable for things
working or not, no matter what political or idealogical happenings go on
at Fedora/Red Hat.
What next, tell me to use Ubuntu?
[1] I am generally very happy with Fedora progress, I just have to keep
reminding myself "everything takes time" :)
[2] Reminds me of when I showed a friend of mine a copy of Linux (fit on
two floppies, no login support etc) and was telling him how cool it was.
His response was "it looks like it sucks pretty bad to me". :(
9:33 p.m.
On Mon, 2007-03-26 at 19:56 -0600, Bernard Johnson wrote:
David Zeuthen wrote:
> Now, if only HP would play nicely with the open source community and
> _just_ provide only drivers instead of reinventing the wheel by
Well, I'm sure you're just emphatic about "better software" but I
think
it comes across as looking a gift horse in the mouth. I mean, what do
you want, junk the hp software and then I can have the same printing
capabilities as when I had this:
http://openprinting.org/show_printer.cgi?recnum=HP-LaserJet_3100
Where are your bug reports to them? Your feature requests? Have you
even interacted with the hplip guys before?
No, I'm not the hplip package owner in any distribution and I just came
across this when looking at doing the ACL support things in HAL for
SANE. I'll probably try to talk to them, I was just shocked we actually
ship these bits.
> - Not only that; starting this daemon is completely useless
unless you
> have HP hardware. We still start it for everyone so everyone have
> to suffer. That's bad.
and so is:
smartd when I don't have a smartd drive
bluethooth when I don't have bluetooth
etc
Two wrongs don't make a right (and, FWIW, I'm actually interacting with
the Bluez guys to make HAL start/stop the bluetooth daemons).
It's nice to sit in your tower and throw rocks, but end then end,
some
of us work with these products and are held accountable for things
working or not, no matter what political or idealogical happenings go on
at Fedora/Red Hat.
I think I said already these are my personal points of view and that I
wasn't speaking for Red Hat and obviously not Fedora. So I'm a bit
unhappy to see you attribute these points of view to Fedora/Red Hat.
Please don't do that. Thanks.
For the record, I know plenty of Fedora people (both inside and outside
of Red Hat) who, like you, are satisfied (and even excited) about the
status quo. Go figure.
David
10:18 p.m.
David Zeuthen wrote:
> Where are your bug reports to them? Your feature requests? Have
you
> even interacted with the hplip guys before?
No, I'm not the hplip package owner in any distribution and I just came
across this when looking at doing the ACL support things in HAL for
SANE. I'll probably try to talk to them, I was just shocked we actually
ship these bits.
I expect you will be pleased with their openness and responsiveness to
making things right. Which is exactly why I queried if you had
expressed your concerns to them.
"shocked"? Seriously David, I'm "shocked" that we still have
these
bugs: bz #218568, bz #177373, bz #216766. Which ones do you think more
people run into? Or do you think more people dig through hplip and say
"this is crap".
And these are direct end-user facing bugs, yet no one is saying let's
not make xen/gnome/etc. visible to the user.
> > - Not only that; starting this daemon is completely
useless unless you
>> have HP hardware. We still start it for everyone so everyone have
>> to suffer. That's bad.
> and so is:
> smartd when I don't have a smartd drive
> bluethooth when I don't have bluetooth
> etc
Two wrongs don't make a right (and, FWIW, I'm actually interacting with
the Bluez guys to make HAL start/stop the bluetooth daemons).
I can't agree more, but let's not set one standard for one piece of
software and not apply it evenly to others.
I don't see anyone filing bz's to remove my bluetooth icons though.
> It's nice to sit in your tower and throw rocks, but end then
end, some
> of us work with these products and are held accountable for things
> working or not, no matter what political or idealogical happenings go on
> at Fedora/Red Hat.
I think I said already these are my personal points of view and that I
wasn't speaking for Red Hat and obviously not Fedora. So I'm a bit
unhappy to see you attribute these points of view to Fedora/Red Hat.
Please don't do that. Thanks.
David, I apologize, this was not at all meant like that. Let me
rephrase that as it was not at all meant to be from a concern of your
working at RH.
Some people are idealistic in this regard. It does not affect their
work, performance, etc. regarding the product. I certainly have an
idealistic flair, but tend to very much be a realist and very pragmatic
when things must get done or must work.
RH/Fedora (employees) still tend to be the primary motivators for making
these sorts of decisions.
IMHO, is the bz # pointed out wrong in a) reason b) motivation c)
assessment, etc. (when compared to other pieces of software) yes.
Will it get changed? No probably not.
Can I point out a dozen or more equally egregious offenders? probably.
If I file bz to have their icons or functionality removed, will they get
removed? probably not.
Seems a bit of a double standard.. no?
For the record, I know plenty of Fedora people (both inside and
outside
of Red Hat) who, like you, are satisfied (and even excited) about the
status quo. Go figure.
What? Let me repeat:
[1] I am generally very happy with Fedora progress, I just have to
keep
reminding myself "everything takes time" :)
(emphasis on *progress*)
Rinse, lather, repeat. But in the interim, it must be usable. <insert
& repeat about being a realist/pragmatist>
11:59 p.m.
On Mon, 2007-03-26 at 21:18 -0600, Bernard Johnson wrote:
David Zeuthen wrote:
>> Where are your bug reports to them? Your feature requests? Have you
>> even interacted with the hplip guys before?
>
> No, I'm not the hplip package owner in any distribution and I just came
> across this when looking at doing the ACL support things in HAL for
> SANE. I'll probably try to talk to them, I was just shocked we actually
> ship these bits.
I expect you will be pleased with their openness and responsiveness to
making things right. Which is exactly why I queried if you had
expressed your concerns to them.
Good to hear. I'm still not the hplip package maintainer though.
Some people are idealistic in this regard. It does not affect their
work, performance, etc. regarding the product. I certainly have an
idealistic flair, but tend to very much be a realist and very pragmatic
when things must get done or must work.
RH/Fedora (employees) still tend to be the primary motivators for making
these sorts of decisions.
I think it's exactly this difference in point of view that is causing
all these heavy flame wars on this and other Fedora lists. In one camp
we have idealistic people that likes to address root problems. In the
other camp we have pragmatic people who will settle for a "quick fix"
even though it means compromising with quality (and not realizing that a
"quick fix" is actually causing the root problem to never get fixed).
Both groups describe each other as being counterproductive. Both groups
knows tricks to get their agenda implemented.
So I honestly don't know what the answer for Fedora is, I wish I did,
but I'm pretty sure that the current state of affairs is not healthy for
the project. And I don't see things getting better, only worse. As Jef
said in a thoughtful mail a while back: Fedora is growing up, soon it
will have hair in funny places. Or something like that.
I can only hope that we can grow a strong contributor base in the Fedora
Project, one that is willing to attack really hard problems without
compromising / throwing bandaids at the problem at hand. One that
doesn't give up even when the flames on fedora-devel gets high. Because
we got to have goals.
David
12:38 a.m.
David Zeuthen wrote:
On Mon, 2007-03-26 at 21:18 -0600, Bernard Johnson wrote:
> David Zeuthen wrote:
>>> Where are your bug reports to them? Your feature requests? Have you
>>> even interacted with the hplip guys before?
>> No, I'm not the hplip package owner in any distribution and I just came
>> across this when looking at doing the ACL support things in HAL for
>> SANE. I'll probably try to talk to them, I was just shocked we actually
>> ship these bits.
> I expect you will be pleased with their openness and responsiveness to
> making things right. Which is exactly why I queried if you had
> expressed your concerns to them.
Good to hear. I'm still not the hplip package maintainer though.
Well, I'm not either :) But I've had *some* interaction with them. I
only mention this because, by your own admission, you will likely end up
in the same boat.
You might be interested in this thread:
http://permalink.gmane.org/gmane.comp.printing.hplip.devel/353
where David Suffield says "... we have learned a lot since we have
started the HPLIP project and we have learned what is useful and what is
not, so we are looking into the possibility of a daemon-less version of
HPLIP."
If you feel strongly about the way that hplip /should/ work, I urge you
to contact them with your views.
1:47 a.m.
Bernard Johnson wrote:
David Zeuthen wrote:
> Now, if only HP would play nicely with the open source community and
> _just_ provide only drivers instead of reinventing the wheel by
Well, I'm sure you're just emphatic about "better software" but I
think
it comes across as looking a gift horse in the mouth. I mean, what do
you want, junk the hp software and then I can have the same printing
capabilities as when I had this:
http://openprinting.org/show_printer.cgi?recnum=HP-LaserJet_3100
(disclaimer: i'm not actually using the hp software...)
But, the whole analogy to looking a gift horse in the mouth is somewhat
mute here, wouldn't you say? Just because corp XYZ throws a pile of
software at the open source community, doesn't mean we have to embrace
it if we don't like it. This is not a gift from anyones grandma, but
from a manufacturer that just wants an easy to use toolset for linux
users. The cause is noble enough, but if the software is less than
ideal, which it appears to be in this case, we are free to choose to do
whatever we want with it.
/Thomas
2:10 a.m.
On 3/27/07, Thomas M Steenholdt <tmus(a)tmus.dk> wrote:
(disclaimer: i'm not actually using the hp software...)
But, the whole analogy to looking a gift horse in the mouth is somewhat
mute here, wouldn't you say? Just because corp XYZ throws a pile of
software at the open source community, doesn't mean we have to embrace
it if we don't like it. This is not a gift from anyones grandma, but
from a manufacturer that just wants an easy to use toolset for linux
users. The cause is noble enough, but if the software is less than
ideal, which it appears to be in this case, we are free to choose to do
whatever we want with it.
In general I agree with you, but the problem is we lack an alternative
package offering the same (or similar) features. In this case,
removing hplip results in someone not being able to work OOTB with its
multifulction printer, which is not the best thing we could do.
I think the best thing is to ship it as is (eventually adding a Fedora
specific icon to fix the problem raised by the original poster) and be
sure to pester upstream for a more SANE approach...
/me goes disabling hplip from each machine in the office
2:20 a.m.
Gianluca Sforna wrote:
On 3/27/07, Thomas M Steenholdt <tmus(a)tmus.dk> wrote:
> (disclaimer: i'm not actually using the hp software...)
>
> But, the whole analogy to looking a gift horse in the mouth is somewhat
> mute here, wouldn't you say? Just because corp XYZ throws a pile of
> software at the open source community, doesn't mean we have to embrace
> it if we don't like it. This is not a gift from anyones grandma, but
> from a manufacturer that just wants an easy to use toolset for linux
> users. The cause is noble enough, but if the software is less than
> ideal, which it appears to be in this case, we are free to choose to do
> whatever we want with it.
In general I agree with you, but the problem is we lack an alternative
package offering the same (or similar) features. In this case,
removing hplip results in someone not being able to work OOTB with its
multifulction printer, which is not the best thing we could do.
I think the best thing is to ship it as is (eventually adding a Fedora
specific icon to fix the problem raised by the original poster) and be
sure to pester upstream for a more SANE approach...
/me goes disabling hplip from each machine in the office
Again, I have to state that I don't know this software, so my discussion
is from a more generic view.
Even if we have no alternative, I'm not sure it's the best thing we can
do, to install software with design/implementation security flaws. If
that is the case, I'd much rather have people pull this from a third
party repository, that installing it by default.
The ideal way, seems to be to convince HP and all other device vendors
to contribute to some of the standard frameworks, to improve on those,
instead of introducing a complete new toolset for every vendor/device
combo (windows style).
/Thomas
3:12 p.m.
David Zeuthen <david <at> fubar.dk> writes:
- Provide their own UI for using the device; just provide the
drivers,
thank you very much; we don't really need foreign tools to make this
harder on the users. Bad.
And we (users of HP printers) are supposed to check the ink levels, clean the
cartridges etc. how then? Where's the non-"foreign" (i.e. non-vendor) tools
to
handle this? Oh wait, there aren't any...
- All the HP stuff, since there is a lot of it, pulls in Qt
So what? How is it better if it pulls in GTK+ instead? Not all the world uses
GNOME... Now they couldn't provide a GUI tool at all, but then see the above
paragraph for why that would be a bad idea.
Instead, for example, HP should get their scanner drivers into the
SANE
project. My personal opinion is that with HPLip, HP is paying lip
service to the Linux community by treating us as if we were Windows
where this sort of "let's throw lots of vendor-specific tools and UI
crap at the user" is common.
My personal opinion is that thanks to hplip, HP printers are the ones which
support Free Software the best.
HP: please try to be a good open source citizen.
Sure, about the daemon, the user-space vfat driver etc., the implementation of
hplip could be less of a mess, but it's all vendor-provided GPL code! There
aren't many vendors doing that. So calling HP "not a good open source
citizen"
just because their GPL code doesn't fit your standards of quality is really
unfair IMHO.
As for the actual issue in this thread, I have a suggestion: what about making
hp-toolbox a separate subpackage of hplip, which is not installed by default,
but which (when installed) comes with a menu item? That would solve both
the "vendor-specific menu item forced on everyone" and the "hplip requires
PyQt" issues.
Kevin Kofler
3:27 a.m.
On Tue, 2007-03-27 at 20:12 +0000, Kevin Kofler wrote:
As for the actual issue in this thread, I have a suggestion: what
about making
hp-toolbox a separate subpackage of hplip, which is not installed by default,
but which (when installed) comes with a menu item? That would solve both
the "vendor-specific menu item forced on everyone" and the "hplip requires
PyQt" issues.
Yes, this is a good idea. Originally it was not possible though: the
'pulls in Qt' problem is due to the fact that the hp-toolbox component
could not be separated out from the transport layer without immense
pain. When I pointed this out upstream they said they would look at
addressing that.
Current versions seem to have a '--enable-gui-build', so it might now
have been addressed. The Qt problem is on the F7 Target list so when I
get some HPLIP time I'll take another look at that.
Tim.
*/
10:16 p.m.
Bernard Johnson wrote:
I was working on finding/reporting some bugs with the hplip package
and
noticed that there was no menu entry. Knowing that a graphical program
with no menu entry wasn't the norm, I was about to file a bug, except
when searching for a duplicate, I came across this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762
mclasen(a)redhat.com:
"We don't give free ad space to HP on our menus..."
I find that to be both an interesting and hypocritical comment.
Bernard has a point. Usability issues (e.g. David's comments) isn't an
excuse for half-hearted packaging. If hplip is in fedora, it ought to be
packaged properly (.desktop menu, icons, and all).
-- Rex
10:23 p.m.
Rex Dieter wrote:
Bernard has a point. Usability issues (e.g. David's comments)
isn't an
excuse for half-hearted packaging. If hplip is in fedora, it ought to be
packaged properly (.desktop menu, icons, and all).
I really hate it when I rant for paragraphs at a time and someone
provides a good three sentence summary :)
And for the record, I am *not against* pulling hplip from Fedora if
that's the consensus. I am however against inconsistency in packages
and application of policies across the distribution.
3:49 p.m.
Bernard Johnson wrote:
And for the record, I am *not against* pulling hplip from Fedora if
that's the consensus. I am however against inconsistency in packages
and application of policies across the distribution.
I don't use it myself but removing a software that supports that many
devices that else would be useless on fedora is simply wrong.
and if we say foo is in the package guidlines but package bar sucks so I
won't honour point x is silly.
either get the package or the guidlines fixed.
4:02 p.m.
On Tue, 2007-03-27 at 22:49 +0200, dragoran wrote:
I don't use it myself but removing a software that supports that many
devices that else would be useless on fedora is simply wrong.
and if we say foo is in the package guidlines but package bar sucks so I
won't honour point x is silly.
either get the package or the guidlines fixed.
Oh, I have complained about that part of the guidelines before, but
without success.
4:28 p.m.
Matthias Clasen wrote:
On Tue, 2007-03-27 at 22:49 +0200, dragoran wrote:
>
> I don't use it myself but removing a software that supports that many
> devices that else would be useless on fedora is simply wrong.
> and if we say foo is in the package guidlines but package bar sucks so I
> won't honour point x is silly.
> either get the package or the guidlines fixed.
>
Oh, I have complained about that part of the guidelines before, but
without success.
And this is primarily where I have a problem.
There is packaging guideline.
You have tried to get them changed, and couldn't.
But that didn't stop you from ignoring them in this particular case.
So take your complaint to remove the icon from the menus to the
packaging committee for an exception to the policy, or a change to the
policy. A heavy handed approach ignoring policy along the way to suit
your personal views is not the right answer.
4:56 p.m.
Bernard Johnson <bjohnson-dated-1172832473.ba5e95 <at> symetrix.com> writes:
So take your complaint to remove the icon from the menus to the
packaging committee for an exception to the policy, or a change to the
policy. A heavy handed approach ignoring policy along the way to suit
your personal views is not the right answer.
What about the subpackage solution I suggested?
As for the actual issue in this thread, I have a suggestion: what
about
making hp-toolbox a separate subpackage of hplip, which is not installed by
default, but which (when installed) comes with a menu item? That would solve
both the "vendor-specific menu item forced on everyone" and the "hplip
requires PyQt" issues.
(Like you, I also think installing GUI programs without a menu entry is bad.
They should be either installed or not installed, not installed-but-hidden.)
Kevin Kofler
5:17 p.m.
Kevin Kofler wrote:
What about the subpackage solution I suggested?
I think it may be possible to split it to a certain extent, but it is
more complicated that most think.
For example... When you print to the scanner, the hpiod(?) program
catches it and stores it until you start the hp-sendfax program. This
program then retrieves the fax and take information like phone number
and such so that it can be sent. If hp-sendfax is not installed faxing
is not functional.
It also appears that the underlying functionality of the python code is
tied intimately to the gui because the program uses PyQT IPC. You can
find the description of that here:
http://permalink.gmane.org/gmane.comp.printing.hplip.devel/250
(Call it a design mistake or whatever)
So I *think* it might be possible to split the hpio* daemons to a base
package (just providing basic printing) and the have all gui and MIO
functions (ie. status, fax, clean, copy, etc) in a subpackage.
Tim Waugh or maybe David Zeuthen would probably be able to better
comment on that.
10:33 p.m.
On Tue, 2007-03-27 at 15:28 -0600, Bernard Johnson wrote:
>
> Oh, I have complained about that part of the guidelines before, but
> without success.
>
And this is primarily where I have a problem.
There is packaging guideline.
You have tried to get them changed, and couldn't.
But that didn't stop you from ignoring them in this particular case.
You have your history wrong here. The bug report that you are citing is
from long before the packaging guidelines were relevant for core
packages.
10:34 p.m.
Matthias Clasen wrote:
On Tue, 2007-03-27 at 15:28 -0600, Bernard Johnson wrote:
>> Oh, I have complained about that part of the guidelines before, but
>> without success.
>>
> And this is primarily where I have a problem.
>
> There is packaging guideline.
>
> You have tried to get them changed, and couldn't.
>
> But that didn't stop you from ignoring them in this particular case.
You have your history wrong here. The bug report that you are citing is
from long before the packaging guidelines were relevant for core
packages.
Sorry, that wasn't meant to be chronological.
But the fact remains that the package is expected to conform to the
package guideline, which is why there is a mass review, to bring all
core packages into compliance.
10:44 p.m.
On Tue, 2007-03-27 at 21:34 -0600, Bernard Johnson wrote:
Sorry, that wasn't meant to be chronological.
But the fact remains that the package is expected to conform to the
package guideline, which is why there is a mass review, to bring all
core packages into compliance.
The packaging committee is not the sole ruler of all things in Fedora,
and the packaging guidelines are just a tool that has its limits. If
something in the packaging guidelines does not make sense for one of my
packages, I will take the freedom to deviate from the guidelines.
12:02 a.m.
Matthias Clasen wrote:
The packaging committee is not the sole ruler of all things in
Fedora,
and the packaging guidelines are just a tool that has its limits. If
something in the packaging guidelines does not make sense for one of my
packages, I will take the freedom to deviate from the guidelines.
It's clear that you intend to do nothing regarding the "right thing", so
this will be my last comment. I don't have the ability to make the
change, only comments and recommendations, which I've put forth.
I did not realize it was your package, I thought it was Tim's.
Regardless, the packaging committee has approved the packaging
guidelines with the goal of improving overall packaging.
You have chosen to ignore the guidelines [1], without any good
/consistent/ reason AFAICS. And I have pointed out several different
places where other packages are not treated the equally, which you have
also ignored.
Fine. But, now it's expected that Fedora packagers apply the guidelines
to themselves while ignoring the fact that you are giving yourself
special treatment for no particularly good reason.[2] Welcome to
hypocrisy and good luck with it.
Are you afraid that the packaging committee might disagree with you if
you asked if your package /should/ be granted an exception regarding
menu entry?
Tell you what, I'll do you one even better, let's both write a paragraph
(no more than 100 words) each and put it in front of the committee for
an opinion of what /should/ be done with this particular package (not
what could be done). If they agree that your actions are warranted, by
a majority (not regarding what you can do, but what you should do), I'll
donate $250 to your favorite free software project. Interested? Email me.
[1] And technically, your package does not violate the guidelines, as
the guidelines only require that the .desktop file be properly
installed, which it is (except for the Category issue I brought up to
Tim). I think most would agree that installing it but not displaying it
violates the intent of the guideline though.
[2] Certainly not the first disagreement from core packages vs.
packaging requirements. Although all the other arguments I've see the
packagers had a compelling reason.
3:45 a.m.
Matthias Clasen wrote:
On Tue, 2007-03-27 at 21:34 -0600, Bernard Johnson wrote:
> Sorry, that wasn't meant to be chronological.
>
> But the fact remains that the package is expected to conform to the
> package guideline, which is why there is a mass review, to bring all
> core packages into compliance.
The packaging committee is not the sole ruler of all things in Fedora,
and the packaging guidelines are just a tool that has its limits. If
something in the packaging guidelines does not make sense for one of my
packages, I will take the freedom to deviate from the guidelines.
Packaging committee is indeed not the role ruler. The reason why they
are called guidelines instead of rules is precisely because there is
sometimes a need for exceptions and to give freedom to the package
maintainers. However individual package maintainers completely
disregarding the guidelines in a arbitrary way is going to be pretty messy.
If there is a justification to deviate from the guidelines it should be
brought in fedora-maintainers list. The guidelines might need to changed
to accommodate requirements the packaging committee hasn't thought of
before or in some corner cases a specific package needs to have a
exception which should be documented within the spec file itself. Can
you do this?
Rahul
4:58 a.m.
dragoran wrote:
Bernard Johnson wrote:
>
> And for the record, I am *not against* pulling hplip from Fedora if
> that's the consensus. I am however against inconsistency in packages
> and application of policies across the distribution.
>
>
I don't use it myself but removing a software that supports that many
devices that else would be useless on fedora is simply wrong.
and if we say foo is in the package guidlines but package bar sucks so I
won't honour point x is silly.
either get the package or the guidlines fixed.
Or orphan the package and let a community member pick it up ?
10:24 p.m.
On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote:
Bernard Johnson wrote:
> I was working on finding/reporting some bugs with the hplip package and
> noticed that there was no menu entry. Knowing that a graphical program
> with no menu entry wasn't the norm, I was about to file a bug, except
> when searching for a duplicate, I came across this:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762
> mclasen(a)redhat.com:
> "We don't give free ad space to HP on our menus..."
> I find that to be both an interesting and hypocritical comment.
Bernard has a point. Usability issues (e.g. David's comments) isn't an
excuse for half-hearted packaging. If hplip is in fedora, it ought to be
packaged properly (.desktop menu, icons, and all).
Blindly following packaging guidelines is not an excuse for poor
usability.
10:40 p.m.
Matthias Clasen wrote:
>> mclasen(a)redhat.com:
>> "We don't give free ad space to HP on our menus..."
>> I find that to be both an interesting and hypocritical comment.
> Bernard has a point. Usability issues (e.g. David's comments) isn't an
> excuse for half-hearted packaging. If hplip is in fedora, it ought to be
> packaged properly (.desktop menu, icons, and all).
Blindly following packaging guidelines is not an excuse for poor
usability.
And I repeat "I can't agree more, but let's not set one standard for one
piece of software and not apply it evenly to others."
Are we willing to apply the same standards to each and every piece of
software in Fedora? (*)
(*) This is a semi-rhetorical question as
a) We all know there are a at least a few "fragile" packages in Fedora
yet we understand that there is a tradeoff between "perfect" and
"usable/delivered".
b) Nobody here is looking for a Debian release cycle :)
12:30 a.m.
On Mon, 2007-03-26 at 23:24 -0400, Matthias Clasen wrote:
On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote:
> Bernard Johnson wrote:
>
> > I was working on finding/reporting some bugs with the hplip package and
> > noticed that there was no menu entry. Knowing that a graphical program
> > with no menu entry wasn't the norm, I was about to file a bug, except
> > when searching for a duplicate, I came across this:
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762
> > mclasen(a)redhat.com:
> > "We don't give free ad space to HP on our menus..."
>
> > I find that to be both an interesting and hypocritical comment.
>
> Bernard has a point. Usability issues (e.g. David's comments) isn't an
> excuse for half-hearted packaging. If hplip is in fedora, it ought to be
> packaged properly (.desktop menu, icons, and all).
Blindly following packaging guidelines is not an excuse for poor
usability.
Do we have an alternative to provide that functionality? If so, sure,
get rid of the poorly behaved software and enable something else in its
place. If not, then we're robbing the user of functionality.
-Toshio
12:41 a.m.
On Mon, 2007-03-26 at 22:30 -0700, Toshio Kuratomi wrote:
Do we have an alternative to provide that functionality? If so,
sure,
get rid of the poorly behaved software and enable something else in its
place. If not, then we're robbing the user of functionality.
-Toshio
There is also Stylus-Toolbox [1].
Perhaps we could integrate a lot of that printer-maintenance work in
CUPS itself somehow?
--
Peter Gordon (codergeek42) / FSF & EFF Member
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
Blog: http://thecodergeek.com/blog/
About: http://fedoraproject.org/wiki/PeterGordon
12:46 a.m.
On Mon, 2007-03-26 at 22:41 -0700, Peter Gordon wrote:
On Mon, 2007-03-26 at 22:30 -0700, Toshio Kuratomi wrote:
> Do we have an alternative to provide that functionality? If so, sure,
> get rid of the poorly behaved software and enable something else in its
> place. If not, then we're robbing the user of functionality.
>
> -Toshio
There is also Stylus-Toolbox [1].
Perhaps we could integrate a lot of that printer-maintenance work in
CUPS itself somehow?
Err, note to self: Always add the footnote if you reference it in your
message. >_<
[1] http://stylus-toolbox.sourceforge.net/
Sorry for the confusion...
--
Peter Gordon (codergeek42) / FSF & EFF Member
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
Blog: http://thecodergeek.com/blog/
About: http://fedoraproject.org/wiki/PeterGordon
12:54 a.m.
Peter Gordon wrote:
On Mon, 2007-03-26 at 22:30 -0700, Toshio Kuratomi wrote:
> Do we have an alternative to provide that functionality? If so, sure,
> get rid of the poorly behaved software and enable something else in its
> place. If not, then we're robbing the user of functionality.
>
> -Toshio
There is also Stylus-Toolbox [1].
Perhaps we could integrate a lot of that printer-maintenance work in
CUPS itself somehow?
hplip also has:
* faxing on a local/network multi-function printer
* setting up copy jobs on a local/network multi-function printer
* scanning on a local/network multi-function printer
* unloading memory cards on a local/network multi-function printer
It appears that Stylus Toolbox does none of this.
1:29 a.m.
On Mon, 2007-03-26 at 23:54 -0600, Bernard Johnson wrote:
hplip also has:
* faxing on a local/network multi-function printer
* setting up copy jobs on a local/network multi-function printer
* scanning on a local/network multi-function printer
* unloading memory cards on a local/network multi-function printer
It appears that Stylus Toolbox does none of this.
Yeah, but what about the more-generic ink level checking, head
alignment/cleaning, et al.? :)
--
Peter Gordon (codergeek42) / FSF & EFF Member
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
Blog: http://thecodergeek.com/blog/
About: http://fedoraproject.org/wiki/PeterGordon
1:34 a.m.
Peter Gordon wrote:
On Mon, 2007-03-26 at 23:54 -0600, Bernard Johnson wrote:
> hplip also has:
>
> * faxing on a local/network multi-function printer
> * setting up copy jobs on a local/network multi-function printer
> * scanning on a local/network multi-function printer
> * unloading memory cards on a local/network multi-function printer
>
>
> It appears that Stylus Toolbox does none of this.
Yeah, but what about the more-generic ink level checking, head
alignment/cleaning, et al.? :)
I guess my message was a bit terse. What I should have said was... I'm
all for integration and leveraging other products to a unified
status/maintenance application, however, hplip does much more that that,
such as: <insert above text here> :)
1:46 a.m.
On Tue, 2007-03-27 at 00:34 -0600, Bernard Johnson wrote:
I guess my message was a bit terse. What I should have said was...
I'm
all for integration and leveraging other products to a unified
status/maintenance application, however, hplip does much more that that,
such as: <insert above text here> :)
I see. Thanks for the clarification.
--
Peter Gordon (codergeek42) / FSF & EFF Member
GnuPG Public Key ID: 0xFFC19479 / Fingerprint:
DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479
Blog: http://thecodergeek.com/blog/
About: http://fedoraproject.org/wiki/PeterGordon
6:44 a.m.
Matthias Clasen wrote:
On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote:
> Bernard has a point. Usability issues (e.g. David's
comments) isn't an
> excuse for half-hearted packaging. If hplip is in fedora, it ought to be
> packaged properly (.desktop menu, icons, and all).
Blindly following packaging guidelines is not an excuse for poor
usability.
David's usability issues have nothing to do with packaging.
If you can justify crippling the packaging, fine, but you haven't.
-- Rex
7:46 a.m.
On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote:
David's usability issues have nothing to do with packaging.
If you can justify crippling the packaging, fine, but you haven't.
Removing a company logo from the menu is a pretty good reason I think. If a
new icon was provided that wasn't advertisement for HP there would be less
resistance to having it in the menu.
--
Jesse Keating
Release Engineer: Fedora
7:51 a.m.
On Tue, 2007-03-27 at 08:46 -0400, Jesse Keating wrote:
On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote:
> David's usability issues have nothing to do with packaging.
> If you can justify crippling the packaging, fine, but you haven't.
Removing a company logo from the menu is a pretty good reason I think. If a
new icon was provided that wasn't advertisement for HP there would be less
resistance to having it in the menu.
How about /usr/share/hplip/data/images/default_printer.png?
Tim.
*/
8:05 a.m.
On Tue, 2007-03-27 at 08:46 -0400, Jesse Keating wrote:
On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote:
> David's usability issues have nothing to do with packaging.
> If you can justify crippling the packaging, fine, but you haven't.
Removing a company logo from the menu is a pretty good reason I think. If a
new icon was provided that wasn't advertisement for HP there would be less
resistance to having it in the menu.
I'd like to point out that there is likely a trademark issue involved
here as well. Unless the package has an explicit grant to display the
HP trademark even if patches are made, I'm sure it'll get sticky.
That might be a bit easier to swallow than "free advertisement".
josh
8:53 a.m.
On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote:
Josh Boyer wrote:
> I'd like to point out that there is likely a trademark issue involved
> here as well.
The package is produced by HP-Development, so I think they can use their own
logo. :)
Firefox is produced by Mozilla, yet we can't use their logo without
going through their process when it comes to patching it. (See the
whole Debian IceWeasle thing.)
Trademarks and open source code don't often play nicely.
josh
9:01 a.m.
Josh Boyer wrote:
On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote:
> Josh Boyer wrote:
> > I'd like to point out that there is likely a trademark
issue involved
> > here as well.
> The package is produced by HP-Development, so I think they can
use their
> own logo. :)
Firefox is produced by Mozilla, yet we can't use their logo
without
going through their process when it comes to patching it.
Firefox isn't GPL'd. The GPL gives us the right to modify and redistribute
without limitation.
-- Rex
9:31 a.m.
Rex Dieter wrote:
Josh Boyer wrote:
> On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote:
>> Josh Boyer wrote:
>>> I'd like to point out that there is likely a trademark issue involved
>>> here as well.
>> The package is produced by HP-Development, so I think they can use their
>> own logo. :)
> Firefox is produced by Mozilla, yet we can't use their logo without
> going through their process when it comes to patching it.
Firefox isn't GPL'd. The GPL gives us the right to modify and redistribute
without limitation.
Firefox *is* under GPL. The whole codebase is trilicensed under
MPL/GPL/LGPL. The license of a software has zero effects on the usage of
a logo which maybe protected by a trademark.
Rahul
9:41 a.m.
Rahul Sundaram wrote:
Rex Dieter wrote:
> Firefox isn't GPL'd. The GPL gives us the right to
modify and
> redistribute without limitation.
Firefox *is* under GPL. The whole codebase is trilicensed under
MPL/GPL/LGPL.
Interesting, only the MPL is mentioned on:
http://www.mozilla.com/en-US/about/licensing.html
but digging deeper I find:
http://www.mozilla.org/MPL/relicensing-faq.html
happy days indeed.
>The license of a software has zero effects on the usage of
a logo which maybe protected by a trademark.
Yuck, murky waters. I figured if an icon/logo was included within GPL
sources, and the GPL allows for unrestricted modification/redistribution,
we were golden. Note, we're not talking about modifying the *trademarked*
item in this case (which I would agree not a good idea), only
using/displaying it.
-- Rex
9:49 a.m.
Rex Dieter wrote:
Yuck, murky waters. I figured if an icon/logo was included within GPL
sources, and the GPL allows for unrestricted modification/redistribution,
we were golden. Note, we're not talking about modifying the *trademarked*
item in this case (which I would agree not a good idea), only
using/displaying it.
Is not like that, consider the Red Hat icons/logos included in the GPL
RHEL sources, a derivative distro is required to change them.
--
nicu
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro
10:02 a.m.
Nicu Buculei wrote:
Rex Dieter wrote:
> Yuck, murky waters. I figured if an icon/logo was included
within GPL
> sources, and the GPL allows for unrestricted modification/redistribution,
> we were golden. Note, we're not talking about modifying the
> *trademarked* item in this case (which I would agree not a good idea),
> only using/displaying it.
Is not like that, consider the Red Hat icons/logos included in the
GPL
RHEL sources, a derivative distro is required to change them.
Yuck (again), my simple-minded non-lawyer common sense tells me such items
shouldn't be using the GPL then, but that's just me.
-- Rex
10:22 a.m.
Rex Dieter wrote:
Nicu Buculei wrote:
> Rex Dieter wrote:
>> Yuck, murky waters. I figured if an icon/logo was included within GPL
>> sources, and the GPL allows for unrestricted modification/redistribution,
>> we were golden. Note, we're not talking about modifying the
>> *trademarked* item in this case (which I would agree not a good idea),
>> only using/displaying it.
> Is not like that, consider the Red Hat icons/logos included in the GPL
> RHEL sources, a derivative distro is required to change them.
Yuck (again), my simple-minded non-lawyer common sense tells me such items
shouldn't be using the GPL then, but that's just me.
The Red Hat logos are not under GPL. The package license of the two
relevant packages and the EULA makes this clear. They are merely part of
the distribution which has components under several different licenses.
Rahul
10:27 a.m.
Rahul Sundaram wrote:
Rex Dieter wrote:
> Yuck (again), my simple-minded non-lawyer common sense tells me
such
> items shouldn't be using the GPL then, but that's just me.
The Red Hat logos are not under GPL. The package license of the two
relevant packages and the EULA makes this clear.
Thanks, though I'd argue mixing-n-matching licenses within a (single)
package is bad form.
-- Rex
10:30 a.m.
On Tue, 2007-03-27 at 10:27 -0500, Rex Dieter wrote:
Rahul Sundaram wrote:
> Rex Dieter wrote:
>> Yuck (again), my simple-minded non-lawyer common sense tells me such
>> items shouldn't be using the GPL then, but that's just me.
> The Red Hat logos are not under GPL. The package license of the two
> relevant packages and the EULA makes this clear.
Thanks, though I'd argue mixing-n-matching licenses within a (single)
package is bad form.
No, there are countless packages with differently licensed files in
them. GPL+LGPL, GPL+(new)BSD, GPL+MIT, MIT+BSD, and on and on and on...
12:17 p.m.
On Tue, Mar 27, 2007 at 11:30:08AM -0400, Simo Sorce wrote:
>
> Thanks, though I'd argue mixing-n-matching licenses within a (single)
> package is bad form.
No, there are countless packages with differently licensed files in
them. GPL+LGPL, GPL+(new)BSD, GPL+MIT, MIT+BSD, and on and on and on...
In those cases the whole package is under the GPL (and, arguably
MIT/BSD are almost the same). When there are other mixes it may be less
clear.
--
Pat
10:18 p.m.
On Tue, 2007-03-27 at 19:17 +0200, Patrice Dumas wrote:
On Tue, Mar 27, 2007 at 11:30:08AM -0400, Simo Sorce wrote:
> >
> > Thanks, though I'd argue mixing-n-matching licenses within a (single)
> > package is bad form.
>
> No, there are countless packages with differently licensed files in
> them. GPL+LGPL, GPL+(new)BSD, GPL+MIT, MIT+BSD, and on and on and on...
In those cases the whole package is under the GPL (and, arguably
MIT/BSD are almost the same). When there are other mixes it may be less
clear.
No, not really, you can have a package that provide different binaries.
For example the samba package is mostly GPL software except for
pam_winbind and nss_winbind, which are not under the GPL. The "whole
package" does not mean much. It's the single binaries+libraries that
count.
I can very well see us distributing something like, let's say Xorg, with
a little GPLed GUI in the same package, this does not make the whole
package GPLed.
Simo.
3:10 a.m.
On Tue, Mar 27, 2007 at 11:18:58PM -0400, Simo Sorce wrote:
No, not really, you can have a package that provide different binaries.
For example the samba package is mostly GPL software except for
pam_winbind and nss_winbind, which are not under the GPL. The "whole
package" does not mean much. It's the single binaries+libraries that
count.
Indeed single binaries and libraries may be under other licenses, but
the src.rpm is GPL.
I can very well see us distributing something like, let's say
Xorg, with
a little GPLed GUI in the same package, this does not make the whole
package GPLed.
If it is a single .src.rpm, it does. Now, as you said above, if the GPL
part can be put in a subpackage, then the remaining subpackages could be
under another license.
--
Pat
8:03 a.m.
On Wed, 2007-03-28 at 10:10 +0200, Patrice Dumas wrote:
On Tue, Mar 27, 2007 at 11:18:58PM -0400, Simo Sorce wrote:
>
> No, not really, you can have a package that provide different binaries.
> For example the samba package is mostly GPL software except for
> pam_winbind and nss_winbind, which are not under the GPL. The "whole
> package" does not mean much. It's the single binaries+libraries that
> count.
Indeed single binaries and libraries may be under other licenses, but
the src.rpm is GPL.
No.
> I can very well see us distributing something like, let's
say Xorg, with
> a little GPLed GUI in the same package, this does not make the whole
> package GPLed.
If it is a single .src.rpm, it does. Now, as you said above, if the GPL
part can be put in a subpackage, then the remaining subpackages could be
under another license.
It does not, go back and read the GPL, the GPL does not apply to other
programs/binaries source even if shipped on the same medium. And a
package is a sort of convenience medium you use to ship sources.
The distribution under GPL terms applies to all the sources that concur
to build a single binary, but does not extend a bit more.
So I can put in a src.rpm 2 related utilities that use 2 different file
sets as sources (maybe sharing just a MIT licensed library also built as
part of the package) and ship them. If one is GPLed the other does not
become automatically GPLed (that would be viral! But the GPL is not).
Simo.
9:53 a.m.
On Wed, Mar 28, 2007 at 09:03:18AM -0400, Simo Sorce wrote:
It does not, go back and read the GPL, the GPL does not apply to other
programs/binaries source even if shipped on the same medium. And a
package is a sort of convenience medium you use to ship sources.
That's certainly what is debatable. Is everything in a src.rpm
covered by the clause 3.b of the GPL.? I thought so, but I may
be wrong. Here is the clause:
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
part of the package) and ship them. If one is GPLed the other does
not
become automatically GPLed (that would be viral! But the GPL is not).
The GPL is viral as the above clause shows, the issue is: is
a src.rpm 'mere aggregation' or a 'work distributed and published...'
I thought that it wasn't mere agregation and that it had to conform
to the clause 3.b. I may be wrong. In any case I think that it could
only be a court that would definitly settle such issue.
--
Pat
10:09 a.m.
Patrice Dumas wrote:
On Wed, Mar 28, 2007 at 09:03:18AM -0400, Simo Sorce wrote:
> It does not, go back and read the GPL, the GPL does not apply to other
> programs/binaries source even if shipped on the same medium. And a
> package is a sort of convenience medium you use to ship sources.
That's certainly what is debatable. Is everything in a src.rpm
covered by the clause 3.b of the GPL.? I thought so, but I may
be wrong. Here is the clause:
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
> part of the package) and ship them. If one is GPLed the other does not
> become automatically GPLed (that would be viral! But the GPL is not).
The GPL is viral as the above clause shows, the issue is: is
a src.rpm 'mere aggregation' or a 'work distributed and published...'
I thought that it wasn't mere agregation and that it had to conform
to the clause 3.b. I may be wrong. In any case I think that it could
only be a court that would definitly settle such issue.
It is mere aggregation since the other parts do not contain or derive
from any software licensed under the GPL. If I licensed my software
under say MIT X11 license then there is simply no way another license
can automatically relicense my software under any different license.
That simply does not work under copyright law. You can however produce a
derivative work if both components are under compatible licenses. The
act of putting distinct packages in the same srpm creates no such
derivative work. See if you can find any relatively well known sources
agreeing with you. IMO this is not a gray area that requires any court
case to clarify.
Rahul
PS: We really really should not be playing lawyers here. If you have a
actual case that would affect Fedora and there is no general consensus
we can ask the real lawyers. Otherwise do take this discussion off
fedora-devel.
11 a.m.
On Wed, 2007-03-28 at 20:39 +0530, Rahul Sundaram wrote:
It is mere aggregation since the other parts do not contain or derive
from any software licensed under the GPL. If I licensed my software
under say MIT X11 license then there is simply no way another license
can automatically relicense my software under any different license.
That simply does not work under copyright law. You can however produce a
derivative work if both components are under compatible licenses. The
act of putting distinct packages in the same srpm creates no such
derivative work. See if you can find any relatively well known sources
agreeing with you. IMO this is not a gray area that requires any court
case to clarify.
+1
Rahul
PS: We really really should not be playing lawyers here. If you have a
actual case that would affect Fedora and there is no general consensus
we can ask the real lawyers. Otherwise do take this discussion off
fedora-devel.
+10
11:22 a.m.
On Wed, Mar 28, 2007 at 08:39:39PM +0530, Rahul Sundaram wrote:
It is mere aggregation since the other parts do not contain or derive
from any software licensed under the GPL. If I licensed my software
under say MIT X11 license then there is simply no way another license
can automatically relicense my software under any different license.
That simply does not work under copyright law. You can however produce a
derivative work if both components are under compatible licenses. The
act of putting distinct packages in the same srpm creates no such
derivative work. See if you can find any relatively well known sources
agreeing with you. IMO this is not a gray area that requires any court
case to clarify.
Ok. I don't remember where I saw that, or if I just imagined it myself.
Rahul
PS: We really really should not be playing lawyers here. If you have a
actual case that would affect Fedora and there is no general consensus
we can ask the real lawyers. Otherwise do take this discussion off
fedora-devel.
In my opinion this is for fedora-devel, since it impacts on reviews.
I have repeatedly annoyed submitters by saying that a src.rpm as a whole
was a derived work of each of the tarballs. Now I stand corrected.
Similarly I have argued that all the files in a tarball needed to be
GPL compatible if there was a single GPL file in the tarball, this seems
to be wrong too, if the 2 files don't have any relationship at link time
and no runtime inclusion (say a C program and a script).
--
Pat
11:41 a.m.
Patrice Dumas wrote:
In my opinion this is for fedora-devel, since it impacts on reviews.
I have repeatedly annoyed submitters by saying that a src.rpm as a whole
was a derived work of each of the tarballs. Now I stand corrected.
Similarly I have argued that all the files in a tarball needed to be
GPL compatible if there was a single GPL file in the tarball, this seems
to be wrong too, if the 2 files don't have any relationship at link time
and no runtime inclusion (say a C program and a script).
I thought you claimed this is one of the reviews and were corrected by
someone else. Make sure you clarify any legal issues in
fedora-maintainers list before enforcing it on reviewers. At any rate it
looks we need a FAQ on common legal issues. If you have a list I can
write it up and run it via Red Hat Legal.
Rahul
3:59 p.m.
On Wed, Mar 28, 2007 at 10:11:18PM +0530, Rahul Sundaram wrote:
I thought you claimed this is one of the reviews and were corrected by
someone else.
The argument was not as clear as your statement.
Make sure you clarify any legal issues in
fedora-maintainers list before enforcing it on reviewers. At any rate it
That's not really possible, there are too many issues arising in
each review.
looks we need a FAQ on common legal issues. If you have a list I can
write it up and run it via Red Hat Legal.
I already asked and Spot responded to most of my issues (especially
the files with author and no license). He agreed more or less with
the practices I proposed, I'll try to find his response, maybe we
could put that, together with the srpm agregation explanation on
the wiki.
--
Pat
11:05 a.m.
On Wed, 2007-03-28 at 16:53 +0200, Patrice Dumas wrote:
On Wed, Mar 28, 2007 at 09:03:18AM -0400, Simo Sorce wrote:
>
> It does not, go back and read the GPL, the GPL does not apply to other
> programs/binaries source even if shipped on the same medium. And a
> package is a sort of convenience medium you use to ship sources.
That's certainly what is debatable. Is everything in a src.rpm
covered by the clause 3.b of the GPL.? I thought so, but I may
be wrong. Here is the clause:
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
> part of the package) and ship them. If one is GPLed the other does not
> become automatically GPLed (that would be viral! But the GPL is not).
The GPL is viral as the above clause shows, the issue is: is
a src.rpm 'mere aggregation' or a 'work distributed and published...'
I thought that it wasn't mere agregation and that it had to conform
to the clause 3.b. I may be wrong. In any case I think that it could
only be a court that would definitly settle such issue.
You are wrong. If that theory were true, it means you could take GPLd
program A, untar the source to directory A, take non-GPLd program B,
untar the source to directory B, and then create a new tarball
containing both of those directories and now both programs must be
licensed under the GPL.
Being in the same tarball, SRPM, CD, DVD, etc. does not make it a
derivative work.
josh
9:58 a.m.
Rex Dieter wrote:
>> The license of a software has zero effects on the usage of
> a logo which maybe protected by a trademark.
Yuck, murky waters. I figured if an icon/logo was included within GPL
sources, and the GPL allows for unrestricted modification/redistribution,
we were golden. Note, we're not talking about modifying the *trademarked*
item in this case (which I would agree not a good idea), only
using/displaying it.
Even if a logo is included within GPL'ed source code, the trademark can
still be protected by separate trademark guidelines. Even use of a
trademark in any form can still be restricted.
Similar separate restrictions apply for patents in the case where the
patent holder is the same entity/people involved in the development of
some software although there is some implicit grant under GPLv2 and a
more explicit one under GPLv3 (in the future based on the current drafts).
In case of other permissive licenses such as revised BSD or MIT X11
license you can be sued by the same people for patent infringement who
gave the software under these licenses. Surprised yet?
Rahul
10:13 a.m.
On Tue, Mar 27, 2007 at 09:41:32AM -0500, Rex Dieter wrote:
Yuck, murky waters. I figured if an icon/logo was included within
GPL
sources, and the GPL allows for unrestricted modification/redistribution,
we were golden. Note, we're not talking about modifying the *trademarked*
item in this case (which I would agree not a good idea), only
using/displaying it.
You'll find most people don't put the icons under the GPL for things like
company logos
9:12 a.m.
Josh Boyer wrote:
On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote:
> Josh Boyer wrote:
>
>> I'd like to point out that there is likely a trademark issue involved
>> here as well.
> The package is produced by HP-Development, so I think they can use their own
> logo. :)
Firefox is produced by Mozilla, yet we can't use their logo without
going through their process when it comes to patching it. (See the
whole Debian IceWeasle thing.)
Right so we do already have a menu entry with a trademarked logo
(firefox), so how would the HP software be any different ?
9:21 a.m.
Le Mar 27 mars 2007 16:12, Denis Leroy a écrit :
Josh Boyer wrote:
> On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote:
>> Josh Boyer wrote:
>>
>>> I'd like to point out that there is likely a trademark issue involved
>>> here as well.
>> The package is produced by HP-Development, so I think they can use
>> their own
>> logo. :)
>
> Firefox is produced by Mozilla, yet we can't use their logo without
> going through their process when it comes to patching it. (See the
> whole Debian IceWeasle thing.)
Right so we do already have a menu entry with a trademarked logo
(firefox), so how would the HP software be any different ?
On one side you have an application logo (1-1 match). On the other side
you have a company logo (1-to-many match). 1st is ok 2nd not.
--
Nicolas Mailhot
8:49 a.m.
Josh Boyer wrote:
On Tue, 2007-03-27 at 08:46 -0400, Jesse Keating wrote:
> On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote:
>> David's usability issues have nothing to do with packaging.
>> If you can justify crippling the packaging, fine, but you haven't.
> Removing a company logo from the menu is a pretty good reason I think. If a
> new icon was provided that wasn't advertisement for HP there would be less
> resistance to having it in the menu.
I'd like to point out that there is likely a trademark issue involved
here as well. Unless the package has an explicit grant to display the
HP trademark even if patches are made, I'm sure it'll get sticky.
That might be a bit easier to swallow than "free advertisement".
And how is not having a menu entry actually solving ANY trademark problem? So
its ok to ship gnometris to as long as we don't put it in the menu?
Regards,
Hans
4:46 p.m.
Josh Boyer wrote:
I'd like to point out that there is likely a trademark issue
involved
here as well. Unless the package has an explicit grant to display the
HP trademark even if patches are made, I'm sure it'll get sticky.
That might be a bit easier to swallow than "free advertisement".
So, I wonder if we also have a grant to the word "bluetooth" since it's
a certification mark? I would guess not.
http://tess2.uspto.gov/bin/showfield?f=doc&state=stgctl.2.8
"THE CERTIFICATION MARK CERTIFIES THAT GOODS MANUFACTURED AND SERVICES
RENDERED BY AUTHORIZED PERSONS COMPLY WITH THE QUALITY AND/OR
INTEROPERABILITY STANDARDS ESTABLISHED BY BLUETOOTH SIG, INC."
8:37 a.m.
Jesse Keating wrote:
On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote:
> David's usability issues have nothing to do with packaging.
> If you can justify crippling the packaging, fine, but you haven't.
Removing a company logo from the menu is a pretty good reason I think.
Why? The software is from HP afterall.
-- Rex
8:57 a.m.
On Tue, 2007-03-27 at 06:44 -0500, Rex Dieter wrote:
Matthias Clasen wrote:
> On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote:
>> Bernard has a point. Usability issues (e.g. David's comments) isn't an
>> excuse for half-hearted packaging. If hplip is in fedora, it ought to be
>> packaged properly (.desktop menu, icons, and all).
> Blindly following packaging guidelines is not an excuse for poor
> usability.
David's usability issues have nothing to do with packaging.
If you can justify crippling the packaging, fine, but you haven't.
I can see the point of putting things in the menus which are explicitly
installed by the user. But to force everything that is in the default
install into the menus just because somebody thought it would be a good
idea to write in the packaging guideline that "every gui app has to have
a desktop file" will quickly lead to unusable menus.
I wonder what people will think about this when more vendors see the
light of open source and we end up with 10 different "print" menu
items, and 10 different system daemons handling some vendors devices
(written in python and pulling in Qt, no less).
8:58 a.m.
Matthias Clasen wrote:
On Tue, 2007-03-27 at 06:44 -0500, Rex Dieter wrote:
> David's usability issues have nothing to do with packaging.
> If you can justify crippling the packaging, fine, but you haven't.
I can see the point of putting things in the menus which are
explicitly
installed by the user. But to force everything that is in the default
install into the menus just because somebody thought it would be a good
idea to write in the packaging guideline that "every gui app has to have
a desktop file" will quickly lead to unusable menus.
See, this is where we apparently disagree. The packaging guideline exists
*because* the to-display-where-or-not decision should not be up to
individual packages/packagers.
This goes beyond packaging policy/guidelines. It is a usability issue, and
should be considered carefully(1) when designing future iterations of
(gnome|kde|redhat)-menus.
(1) Usability a SIG/group would come in handy here, oh maybe something like:
http://fedoraproject.org/wiki/Usability
-- Rex
11:21 a.m.
Matthias Clasen wrote:
I can see the point of putting things in the menus which are
explicitly
installed by the user. But to force everything that is in the default
install into the menus just because somebody thought it would be a good
idea to write in the packaging guideline that "every gui app has to have
a desktop file" will quickly lead to unusable menus.
But let's look at why it's in the default install:
http://hplip.sourceforge.net/
"The HPLIP project provides printing support for 1,139 printer models,
including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy),
Business Inkjet, LaserJet, and LaserJet MFP."
1139 is not an insignificant number. Oh, and the fact that we don't
have the ability to decide intelligently if it needs to be installed.
I wonder what people will think about this when more vendors see the
light of open source and we end up with 10 different "print" menu
items, and 10 different system daemons handling some vendors devices
(written in python and pulling in Qt, no less).
Then this is a failure of the packaging or packaging process. It has
nothing to do with the individual package.
11:51 a.m.
Bernard Johnson píše v Út 27. 03. 2007 v 10:21 -0600:
Matthias Clasen wrote:
> I can see the point of putting things in the menus which are explicitly
> installed by the user. But to force everything that is in the default
> install into the menus just because somebody thought it would be a good
> idea to write in the packaging guideline that "every gui app has to have
> a desktop file" will quickly lead to unusable menus.
But let's look at why it's in the default install:
http://hplip.sourceforge.net/
"The HPLIP project provides printing support for 1,139 printer models,
including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy),
Business Inkjet, LaserJet, and LaserJet MFP."
1139 is not an insignificant number. Oh, and the fact that we don't
have the ability to decide intelligently if it needs to be installed.
But it could be a task for system-config-printer - it detects printers
and installs printer specific packages. It could be perhaps some
connection between driver name and required packages.
Dan
3:29 a.m.
On Tue, 2007-03-27 at 18:51 +0200, Dan Horák wrote:
But it could be a task for system-config-printer - it detects
printers
and installs printer specific packages. It could be perhaps some
connection between driver name and required packages.
It does in fact already do this. :-)
Unfortunately I don't know of a good hook for 'now install this package,
prompting the user first', so all it currently does it tell the user the
name of the package they should install.
Anyone know how to make that better?
Tim.
*/
8:15 a.m.
On Wed, 2007-03-28 at 09:29 +0100, Tim Waugh wrote:
On Tue, 2007-03-27 at 18:51 +0200, Dan Horák wrote:
> But it could be a task for system-config-printer - it detects printers
> and installs printer specific packages. It could be perhaps some
> connection between driver name and required packages.
It does in fact already do this. :-)
Unfortunately I don't know of a good hook for 'now install this package,
prompting the user first', so all it currently does it tell the user the
name of the package they should install.
Anyone know how to make that better?
The system-install-packages tool included in pirut has support now for
just giving package names in addition to local packages. That gives a
pretty easy way to launch "install a package named foo"
Jeremy
12:03 p.m.
On Tue, 2007-03-27 at 10:21 -0600, Bernard Johnson wrote:
Matthias Clasen wrote:
> I can see the point of putting things in the menus which are explicitly
> installed by the user. But to force everything that is in the default
> install into the menus just because somebody thought it would be a good
> idea to write in the packaging guideline that "every gui app has to have
> a desktop file" will quickly lead to unusable menus.
But let's look at why it's in the default install:
http://hplip.sourceforge.net/
"The HPLIP project provides printing support for 1,139 printer models,
including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy),
Business Inkjet, LaserJet, and LaserJet MFP."
1139 is not an insignificant number. Oh, and the fact that we don't
have the ability to decide intelligently if it needs to be installed.
How many of these are not supported by cups/foomatic ?
> I wonder what people will think about this when more vendors see
the
> light of open source and we end up with 10 different "print" menu
> items, and 10 different system daemons handling some vendors devices
> (written in python and pulling in Qt, no less).
Then this is a failure of the packaging or packaging process. It has
nothing to do with the individual package.
I don't follow you here. I'm making the argument that this individual
package installs a resource hungry system daemon that always runs even
if it has nothing to do, and the ui duplicates a good chunk of the
printing support in the rest of the desktop. And you say that has
nothing to do with the individual package ?
11:52 a.m.
Matthias Clasen wrote:
On Tue, 2007-03-27 at 10:21 -0600, Bernard Johnson wrote:
> Matthias Clasen wrote:
>> I can see the point of putting things in the menus which are explicitly
>> installed by the user. But to force everything that is in the default
>> install into the menus just because somebody thought it would be a good
>> idea to write in the packaging guideline that "every gui app has to have
>> a desktop file" will quickly lead to unusable menus.
> But let's look at why it's in the default install:
>
> http://hplip.sourceforge.net/
> "The HPLIP project provides printing support for 1,139 printer models,
> including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy),
> Business Inkjet, LaserJet, and LaserJet MFP."
>
> 1139 is not an insignificant number. Oh, and the fact that we don't
> have the ability to decide intelligently if it needs to be installed.
How many of these are not supported by cups/foomatic ?
I really get the feeling you would rather punish users because it
doesn't work the way you want it to.
The fact is that it supports a lot of printers.
>> I wonder what people will think about this when more vendors
see the
>> light of open source and we end up with 10 different "print" menu
>> items, and 10 different system daemons handling some vendors devices
>> (written in python and pulling in Qt, no less).
> Then this is a failure of the packaging or packaging process. It has
> nothing to do with the individual package.
I don't follow you here. I'm making the argument that this individual
package installs a resource hungry system daemon that always runs even
if it has nothing to do, and the ui duplicates a good chunk of the
printing support in the rest of the desktop. And you say that has
nothing to do with the individual package ?
Whether or not the software sucks is another issue. If we are
installing software for hardware that people do not have, and then
multiple instances of programs that have identical functionality, that
is a packaging problem. Even if hplip was the best software in the
world it would not fix that.
Should we talk about the fact that Fedora already has three copies of
VNC-type programs without an integrated codebase?
3:16 p.m.
Bernard Johnson wrote:
I was working on finding/reporting some bugs with the hplip package
and
noticed that there was no menu entry. Knowing that a graphical program
with no menu entry wasn't the norm, I was about to file a bug, except
when searching for a duplicate, I came across this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762
mclasen(a)redhat.com:
"We don't give free ad space to HP on our menus..."
3) And the in F7, there will be CodecBuddy
(http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy) which will
direct users to the Fluendo Webshop (https://shop.fluendo.com/) to
purchase proprietary codes when they try to play media that they do not
have a code for (http://hadessuk.blogspot.com/2007/03/totem-news.html).
Although I originally posted regarding the hp-toolbox bug, I had hoped
for a much wider opinion regarding advertising (and the discussion as it
turned to trademarks as well).
Are we ok with letting CodecBuddy direct users to the Fluendo webstore?
Are there going to be providions for equal access for other vendors?
Also, for example. CUPS admin page has the "Easy Software Products"
logo, and a link to the "Pro" version of the product and the companies
home page which has products for sale. Is this ok?
3:28 p.m.
Once upon a time, Bernard Johnson <bjohnson-dated-1172832473.ba5e95(a)symetrix.com>
said:
Also, for example. CUPS admin page has the "Easy Software
Products"
logo, and a link to the "Pro" version of the product and the companies
home page which has products for sale. Is this ok?
IIRC the MySQL initial setup script advertises that MySQL.com sells
commercial licenses. Is someone going to go through and "audit" for
this kind of thing? What are you going to do - remove such messages?
That is kind of rude to the people working to provide software freely.
I have HP laser printers both at home and at work, and this discussion
is the first I had heard of the HP tools. I just checked them out, and
they look useful for HP users. What is the objection? Every other app
(at least GUI apps) gets a menu entry, and that includes an app-chosen
logo/icon. Why is this one any different (as long as the image license
is suitable)?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:45 p.m.
On Tuesday 27 March 2007 16:16:59 Bernard Johnson wrote:
Are we ok with letting CodecBuddy direct users to the Fluendo
webstore?
Are there going to be providions for equal access for other vendors?
I personally had thought that codecbuddy was going to drive users to a
fedoraproject.org page which would give more information and list possible
vendors for the codec. If Fluendo is the only possible vendor, that's fine,
but we would own the page that codecbuddy drives to and thus own the content
listed and could add/remove vendors at our will. Is that not the case?
--
Jesse Keating
Release Engineer: Fedora
4:27 p.m.
Jesse Keating wrote:
On Tuesday 27 March 2007 16:16:59 Bernard Johnson wrote:
> Are we ok with letting CodecBuddy direct users to the Fluendo webstore?
> Are there going to be providions for equal access for other vendors?
I personally had thought that codecbuddy was going to drive users to a
fedoraproject.org page which would give more information and list possible
vendors for the codec. If Fluendo is the only possible vendor, that's fine,
but we would own the page that codecbuddy drives to and thus own the content
listed and could add/remove vendors at our will. Is that not the case?
Unfortunately, I don't think there is enough in rawhide to preview. You
might be right (and your description would probably work great and be
fair), but...
My assumption was based on
http://hadessuk.blogspot.com/2007/03/totem-news.html
In this screenshot, it looks like the application is pulling the
information directly from the Fluendo webshop (their description, their
price).
4:42 p.m.
On Tuesday 27 March 2007 17:27:55 Bernard Johnson wrote:
My assumption was based on
http://hadessuk.blogspot.com/2007/03/totem-news.html
In this screenshot, it looks like the application is pulling the
information directly from the Fluendo webshop (their description, their
price).
Surely where a codecbuddy points to would be configurable by the distribution
packaging it up. The upstream codecbuddy needs a default place to point to,
and that may well be fluendo. However as a downstream, we can choose to
point it wherever we as a distribution feel it should go.
--
Jesse Keating
Release Engineer: Fedora
5:36 p.m.
Bernard Johnson wrote:
Jesse Keating wrote:
> On Tuesday 27 March 2007 16:16:59 Bernard Johnson wrote:
>> Are we ok with letting CodecBuddy direct users to the Fluendo webstore?
>> Are there going to be providions for equal access for other vendors?
> I personally had thought that codecbuddy was going to drive users to a
> fedoraproject.org page which would give more information and list possible
> vendors for the codec. If Fluendo is the only possible vendor, that's fine,
> but we would own the page that codecbuddy drives to and thus own the content
> listed and could add/remove vendors at our will. Is that not the case?
Unfortunately, I don't think there is enough in rawhide to preview. You
might be right (and your description would probably work great and be
fair), but...
My assumption was based on
http://hadessuk.blogspot.com/2007/03/totem-news.html
In this screenshot, it looks like the application is pulling the
information directly from the Fluendo webshop (their description, their
price).
The way UI works on the codec buddy is described in the blog is not what
will be ultimately in Fedora. I brought this up on Fedora Board meeting
today. Here is how it is expected to work.
* When the user clicks a mp3 file, instead of missing codec errors
there will be a popup where the user can either choose to learn about
Free (in both ways) alternatives or click to install the free codec
supplied by Fluendo (Fleundo has the necessary patent licenses so this
is a legal in US) which is under a MIT X11 license or cancel the whole
thing. The user experience here is very similar to what happens when
you visit a website which needs Flash plugin the first time in Firefox
except that in addition we would explain to them that there are better
Free alternatives and the reason why we don't provide these codecs by
default in Fedora. This way we get to keep Fedora entirely Free and open
source software while solving the usability issue of not being able to
play some of the content to a good extend (wont be very helpful folks
who dont network access so it is not 100% solved yet).
* For the other paid as well as proprietary codecs, the user would be
directed to a Fedora Project page where they can again learn about
better Free alternatives. In the page we would also list Fluendo as a
vendor providing licensed and paid proprietary codecs. If there are
vendors who are involved we can very well list them. So there is a level
playing field here.
Comments?
Rahul
6:15 p.m.
Rahul Sundaram wrote:
* When the user clicks a mp3 file, instead of missing codec errors
there will be a popup where the user can either choose to learn about
Free (in both ways) alternatives or click to install the free codec
supplied by Fluendo (Fleundo has the necessary patent licenses so this
is a legal in US) which is under a MIT X11 license or cancel the whole
thing. The user experience here is very similar to what happens when
you visit a website which needs Flash plugin the first time in Firefox
except that in addition we would explain to them that there are better
Free alternatives and the reason why we don't provide these codecs by
default in Fedora. This way we get to keep Fedora entirely Free and open
source software while solving the usability issue of not being able to
play some of the content to a good extend (wont be very helpful folks
who dont network access so it is not 100% solved yet).
* For the other paid as well as proprietary codecs, the user would be
directed to a Fedora Project page where they can again learn about
better Free alternatives. In the page we would also list Fluendo as a
vendor providing licensed and paid proprietary codecs. If there are
vendors who are involved we can very well list them. So there is a level
playing field here.
Comments?
Thank you for the clarification. The only problem I see, if I
understand you, is that the mp3 codec is sole-sourced to Fluendo. I
understand that Fluendo is the only vendor to providing a legal
alternative today, but we should have the ability to allow multiple
vendors at that step.
6:52 p.m.
Bernard Johnson wrote:
Thank you for the clarification. The only problem I see, if I
understand you, is that the mp3 codec is sole-sourced to Fluendo. I
understand that Fluendo is the only vendor to providing a legal
alternative today, but we should have the ability to allow multiple
vendors at that step.
We do it this way because
* Fleundo is the company that employs many (most?) of the gstreamer
developers that provides us with a Free multimedia framework. This is
one way of acknowledging their efforts.
* It is a gratis solution and a commonly requested feature.
* If we provide redirects it is just a additional step over making it a
click through option which is more usable. Like you said there really
isn't any choice of vendors to provide the same feature and providing a
theoretical level playing feature for a gratis component does not appear
to important as opposed to the usability advantage at this point.
If there are other vendors in the future we can reconsider what we need
to do. The hooks for codec buddy are already in upstream gstreamer,
nothing is hard coded and we can change this very easily.
Rahul
8:04 p.m.
Rahul Sundaram wrote:
Bernard Johnson wrote:
> Thank you for the clarification. The only problem I see, if I
> understand you, is that the mp3 codec is sole-sourced to Fluendo. I
> understand that Fluendo is the only vendor to providing a legal
> alternative today, but we should have the ability to allow multiple
> vendors at that step.
We do it this way because
* Fleundo is the company that employs many (most?) of the gstreamer
developers that provides us with a Free multimedia framework. This is
one way of acknowledging their efforts.
For the record, I am not against this at all... but
* Hewlett Packard is the company that employs many of the hplip
developers that provide the free hplip software. This software supports
1100+ printer models.
* It is a gratis solution and a commonly requested feature.
The hplip software is GPL and not intentionally feature-limited in any
way. One must assume that if you want to print to your HP printer, it
would be a commonly requested feature given the market penetration of
HP. (It was important enough to include at FC-4 anyway)
* If we provide redirects it is just a additional step over making it
a
click through option which is more usable. Like you said there really
isn't any choice of vendors to provide the same feature and providing a
theoretical level playing feature for a gratis component does not appear
to important as opposed to the usability advantage at this point.
There are no vendors that provide the same level of functionality as the
hplip software.
If there are other vendors in the future we can reconsider what we
need
to do. The hooks for codec buddy are already in upstream gstreamer,
nothing is hard coded and we can change this very easily.
Today, we do not allow the hp-toolbox to have an icon on the menu.
Now,
I do not disagree with the direction taken with CodecBuddy (this I
stated in my original email). I very much disagree with lack of
impartiality between vendors who are both supporting Linux.
Given that the original argument against the hp-toolbox menu item was
because it was advertising, the Fluendo agreement goes /far/ beyond that.
I should also point that that the "advertising" HP gets has no directly
-tied revenue (ie. it doesn't not direct anyone to a website to purchase
anything). At the same time, Fluendo will directly profit from the
CodecBuddy tie-in.
And please, before anyone goes down the "but I don't like the HP
software" rant road, get a reality check. Show me software that can be
used to get the same functionality.
We told HP that we wanted Linux support, and not only did they give us
printing support, they supported the whole MIO ball of wax. As far as I
understand it, they are also paying for the continued development of the
software AND support in the newsgroups.
Compare that to Broadcom(wireless)/Nvidia/ATI who we also asked to
support Linux. Two companies gave us blobs and said "trust us, it's
great software!", while another said "get bent"[1] and the only reason
we have support at all today with this vendor is because someone reverse
engineered the chip and developed the ability to load a firmware blob.
All the "free software zealots" say to vote with your pocketbook. I
did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And
not just a blob, real GPL software. Now I hear total bogus arguments
like "it's advertising" [but don't look at these other things that are
advertising as well that we will let slide] or "yeah, it's free but it's
not good enough"[2][3].
This is exactly the attitude that will cause Linux to not get any
support by vendors.
The fact of the matter is that it takes vendor support to make
Fedora/RedHat anything other than a toy operating system for many uses.
At many junctures, we have to make conscious trade offs between
idealogical beliefs and functionality. That trade off may be a little
recognition of the hard work that someone / some company put into the
software, and I say that's great, give it to them.
But to actually go out of your way to make it harder for the end-user it
beyond comprehension. There are already multiple bugs filed on this
issue, and I would have filed one too had I not looked at the spec file.
It's not like Linux doesn't have enough hurdles (potential patent
pitfalls, trademark issues[4], brand recognition, user-base
fragmentation, etc), let's not create more problems just for the fun of it.
[1] That wasn't the real response, but since they are ignoring the
issue, it's clear that they don't care.
[2] Where "good enough" seems to be based on idealism and by people who
don't even use the software.
[3] I can consistently break the bcm43xx stack, but you don't see me
screaming that it sucks and we should disable it.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233729
[4] See my response in this thread regarding potential bluetooth problems.
10:47 p.m.
Bernard,
I can't agree more with what you said, this discussion is silly, it
start reminding me some of the more brain-damaged discussions on Debian
lists. I hope it is an isolate incident, and is not becoming the norm or
next we will declare that Trademarks, documentation, and just everything
in the world is software and any license but the GPL is bad.
Don't get me wrong, I love the GPL, it is the license I use for my
software, but _software_ is the key here. Names, logos, documentation
are a different matter. Please let's not get stupid and let's recognize
things from what they are.
Trademarks, are not good or bad by themselves, it is the use you do of
them that can be good or bad. HP's trademark/logo in hp-toolbox is on
the side of the "good" way much more than what is the Mozilla's Firefox
trademark/logo.
On Tue, 2007-03-27 at 19:04 -0600, Bernard Johnson wrote:
All the "free software zealots" say to vote with your
pocketbook. I
did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And
not just a blob, real GPL software. Now I hear total bogus arguments
like "it's advertising" [but don't look at these other things that are
advertising as well that we will let slide] or "yeah, it's free but it's
not good enough"[2][3].
HP People didn't attach any string to the use of that logo for that
software, so any discussion about removing it, is just plain silly, IMO.
We are beyond "free software zealots" we reached the point of "berserk
kamikaze zealots" if we actually go down this road.
This is exactly the attitude that will cause Linux to not get any
support by vendors.
Wise words. We need more software not less, there is still a *LOT* of
software niches that have no sort of free software of any kind, and
pretty big ones.
And people here waste time arguing by a trademarked logo in a GPL
package that comes with no sort of requirements? Are you insane? Or
what?
The fact of the matter is that it takes vendor support to make
Fedora/RedHat anything other than a toy operating system for many uses.
At many junctures, we have to make conscious trade offs between
idealogical beliefs and functionality. That trade off may be a little
recognition of the hard work that someone / some company put into the
software, and I say that's great, give it to them.
If only this little "advertising" could be used to make more companies
write and distribute GPL software I would ask for MORE of this kind
advertising, that would be just great.
On the software quality I would really avoid commenting, we have such
crap in free software that complaining about the quality of *useful*
*free software* is beyond my comprehension. When the people that don't
like it, will rewrite and support a better piece of software to cover
the same functionality, then they will be entitled to speak about
removing others software.
Please, I beg you try to use your head and think:
a) what is the right thing to do to help users (NOW, not "in 10 years
maybe") with *free software*
b) what is the right thing to do to spread more *free software*
c) what is the right way to get more vendors to help us with *free
software*
d) what is the right thing to do to avoid waisting time and produce more
*free software*
To me the answers are pretty clear wrt this case.
Simo.
11:22 p.m.
Simo Sorce wrote:
Wise words. We need more software not less, there is still a *LOT*
of
software niches that have no sort of free software of any kind, and
pretty big ones.
If we make Fedora usable, we attract users (not just developers, but
users). Users put pressure on vendors. Vendors bring more/better/open
software and developers.
Making tools that users expect to have hard to use or find, even when
they are functional and freely available, moves in exactly the opposite
direction.
Please, I beg you try to use your head and think:
a) what is the right thing to do to help users (NOW, not "in 10 years
maybe") with *free software*
And I think you should stress the "maybe". Remember FSF saying "just
wait the hurd is coming" lol
2:04 p.m.
On Tue, 27 Mar 2007, Simo Sorce wrote:
Bernard,
I can't agree more with what you said, this discussion is silly, it
start reminding me some of the more brain-damaged discussions on Debian
lists. I hope it is an isolate incident, and is not becoming the norm or
next we will declare that Trademarks, documentation, and just everything
in the world is software and any license but the GPL is bad.
Don't get me wrong, I love the GPL, it is the license I use for my
software, but _software_ is the key here. Names, logos, documentation
are a different matter. Please let's not get stupid and let's recognize
things from what they are.
Trademarks, are not good or bad by themselves, it is the use you do of
them that can be good or bad. HP's trademark/logo in hp-toolbox is on
the side of the "good" way much more than what is the Mozilla's Firefox
trademark/logo.
On Tue, 2007-03-27 at 19:04 -0600, Bernard Johnson wrote:
> All the "free software zealots" say to vote with your pocketbook. I
> did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And
> not just a blob, real GPL software. Now I hear total bogus arguments
> like "it's advertising" [but don't look at these other things that
are
> advertising as well that we will let slide] or "yeah, it's free but
it's
> not good enough"[2][3].
HP People didn't attach any string to the use of that logo for that
software, so any discussion about removing it, is just plain silly, IMO.
We are beyond "free software zealots" we reached the point of "berserk
kamikaze zealots" if we actually go down this road.
> This is exactly the attitude that will cause Linux to not get any
> support by vendors.
Wise words. We need more software not less, there is still a *LOT* of
software niches that have no sort of free software of any kind, and
pretty big ones.
And people here waste time arguing by a trademarked logo in a GPL
package that comes with no sort of requirements? Are you insane? Or
what?
> The fact of the matter is that it takes vendor support to make
> Fedora/RedHat anything other than a toy operating system for many uses.
> At many junctures, we have to make conscious trade offs between
> idealogical beliefs and functionality. That trade off may be a little
> recognition of the hard work that someone / some company put into the
> software, and I say that's great, give it to them.
If only this little "advertising" could be used to make more companies
write and distribute GPL software I would ask for MORE of this kind
advertising, that would be just great.
On the software quality I would really avoid commenting, we have such
crap in free software that complaining about the quality of *useful*
*free software* is beyond my comprehension. When the people that don't
like it, will rewrite and support a better piece of software to cover
the same functionality, then they will be entitled to speak about
removing others software.
Please, I beg you try to use your head and think:
a) what is the right thing to do to help users (NOW, not "in 10 years
maybe") with *free software*
b) what is the right thing to do to spread more *free software*
c) what is the right way to get more vendors to help us with *free
software*
d) what is the right thing to do to avoid waisting time and produce more
*free software*
To me the answers are pretty clear wrt this case.
Simo.
I can't agree more with Bernard and Simo. Rampant masochism is the real
enemy of free software.
Alfredo
BTW I bought a multifunction HP printer/scanner/fax etc JUST BECAUSE
it was fully and freely supported in Linux...
--
+----------------------------------------------------------------------------+
| Alfredo Ferrari || Tel.: +41.22.767.6119 |
| C.E.R.N. || Fax.: +41.22.767.7555 |
| European Laboratory for Particle Physics|| |
| AB Division / ATB Group || e-mail: |
| 1211 Geneva 23 || Alfredo.Ferrari(a)cern.ch |
| Switzerland || Alfredo.Ferrari(a)mi.infn.it |
+----------------------------------------------------------------------------+
3:19 p.m.
On 3/28/07, Alfredo Ferrari <list(a)pceet030.cern.ch> wrote:
On Tue, 27 Mar 2007, Simo Sorce wrote:
>
> Bernard,
> I can't agree more with what you said, this discussion is silly, it
> start reminding me some of the more brain-damaged discussions on Debian
> lists. I hope it is an isolate incident, and is not becoming the norm or
> next we will declare that Trademarks, documentation, and just everything
> in the world is software and any license but the GPL is bad.
>
> Don't get me wrong, I love the GPL, it is the license I use for my
> software, but _software_ is the key here. Names, logos, documentation
> are a different matter. Please let's not get stupid and let's recognize
> things from what they are.
>
> Trademarks, are not good or bad by themselves, it is the use you do of
> them that can be good or bad. HP's trademark/logo in hp-toolbox is on
> the side of the "good" way much more than what is the Mozilla's
Firefox
> trademark/logo.
>
> On Tue, 2007-03-27 at 19:04 -0600, Bernard Johnson wrote:
>> All the "free software zealots" say to vote with your pocketbook. I
>> did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And
>> not just a blob, real GPL software. Now I hear total bogus arguments
>> like "it's advertising" [but don't look at these other things
that are
>> advertising as well that we will let slide] or "yeah, it's free but
it's
>> not good enough"[2][3].
>
> HP People didn't attach any string to the use of that logo for that
> software, so any discussion about removing it, is just plain silly, IMO.
>
> We are beyond "free software zealots" we reached the point of
"berserk
> kamikaze zealots" if we actually go down this road.
>
>> This is exactly the attitude that will cause Linux to not get any
>> support by vendors.
>
> Wise words. We need more software not less, there is still a *LOT* of
> software niches that have no sort of free software of any kind, and
> pretty big ones.
>
> And people here waste time arguing by a trademarked logo in a GPL
> package that comes with no sort of requirements? Are you insane? Or
> what?
>
>> The fact of the matter is that it takes vendor support to make
>> Fedora/RedHat anything other than a toy operating system for many uses.
>> At many junctures, we have to make conscious trade offs between
>> idealogical beliefs and functionality. That trade off may be a little
>> recognition of the hard work that someone / some company put into the
>> software, and I say that's great, give it to them.
>
> If only this little "advertising" could be used to make more companies
> write and distribute GPL software I would ask for MORE of this kind
> advertising, that would be just great.
>
> On the software quality I would really avoid commenting, we have such
> crap in free software that complaining about the quality of *useful*
> *free software* is beyond my comprehension. When the people that don't
> like it, will rewrite and support a better piece of software to cover
> the same functionality, then they will be entitled to speak about
> removing others software.
>
> Please, I beg you try to use your head and think:
>
> a) what is the right thing to do to help users (NOW, not "in 10 years
> maybe") with *free software*
> b) what is the right thing to do to spread more *free software*
> c) what is the right way to get more vendors to help us with *free
> software*
> d) what is the right thing to do to avoid waisting time and produce more
> *free software*
>
> To me the answers are pretty clear wrt this case.
>
> Simo.
>
>
I can't agree more with Bernard and Simo. Rampant masochism is the real
enemy of free software.
Alfredo
BTW I bought a multifunction HP printer/scanner/fax etc JUST BECAUSE
it was fully and freely supported in Linux...
Me too, I had no idea there was such apparent hatred of the solution.
--
Fedora Core 6 and proud
3:20 p.m.
Alfredo Ferrari wrote:
BTW I bought a multifunction HP printer/scanner/fax etc JUST BECAUSE
it was fully and freely supported in Linux...
/me too,
Can we please stop the HP bashing, they are doing a great job in providing
support for their hardware, if their tools need better integration into the
rest of Linux, then work with them, instead of bashing them / their software.
Regards,
Hans
5:17 p.m.
On Wednesday 28 March 2007 16:20:24 Hans de Goede wrote:
/me too,
Can we please stop the HP bashing, they are doing a great job in providing
support for their hardware, if their tools need better integration into the
rest of Linux, then work with them, instead of bashing them / their
software.
I'd wager their tools need to be better period.
I just unpacked a new HP photosmart C3180 multipurpose thingy. I wanted to
print out my flight eticket. After all this discussion I figured I'd give it
a try. After powering on and attaching the printer via usb, I ask yum to
install hplip. After downloading a 10+ megs of software, I had hplip on my
system. I tried to <alt>-f2 and typed in hp-toolbox as that would be what
the menu called. Nothing. Tried again, nothing. The hell? Try it from a
console, HO! A daemon isn't running and so the software just yells about not
being able to connect to "HPLIP I/O (hpiod)" whatever the hell that is.
Helpful. Being a bit cluefull about these things, I guess it wants the hplip
service to be running. So start the daemon, try again, and I get a big
screen about no installed HP devices found. Ok, there is a setup device
button, click it, nothing detected. Find Manually asks me for a cryptic USB
ID which it gives me no clue as how to find it. Helpful.
So I give up on this, close it, stop the service.
I instead try System -> Administration -> Printing
New printer
Fill in details about name, description, location
Hit next and look at that, it automatically detected I had a USB printer
plugged in and even had the right name. Forward again, pick the closest HP
driver from the list (HP Photosmart C3100) finalize and boom I can print a
test job, and furthermore print my etickets.
Yeah, this is great software allright. *sigh*
--
Jesse Keating
Release Engineer: Fedora
6:20 p.m.
On 3/28/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Wednesday 28 March 2007 16:20:24 Hans de Goede wrote:
> /me too,
>
> Can we please stop the HP bashing, they are doing a great job in providing
> support for their hardware, if their tools need better integration into the
> rest of Linux, then work with them, instead of bashing them / their
> software.
I'd wager their tools need to be better period.
I just unpacked a new HP photosmart C3180 multipurpose thingy. I wanted to
print out my flight eticket. After all this discussion I figured I'd give it
a try. After powering on and attaching the printer via usb, I ask yum to
install hplip. After downloading a 10+ megs of software, I had hplip on my
system. I tried to <alt>-f2 and typed in hp-toolbox as that would be what
the menu called. Nothing. Tried again, nothing. The hell? Try it from a
console, HO! A daemon isn't running and so the software just yells about not
being able to connect to "HPLIP I/O (hpiod)" whatever the hell that is.
Helpful. Being a bit cluefull about these things, I guess it wants the hplip
service to be running. So start the daemon, try again, and I get a big
screen about no installed HP devices found. Ok, there is a setup device
button, click it, nothing detected. Find Manually asks me for a cryptic USB
ID which it gives me no clue as how to find it. Helpful.
So I give up on this, close it, stop the service.
I instead try System -> Administration -> Printing
New printer
Fill in details about name, description, location
Hit next and look at that, it automatically detected I had a USB printer
plugged in and even had the right name. Forward again, pick the closest HP
driver from the list (HP Photosmart C3100) finalize and boom I can print a
test job, and furthermore print my etickets.
Yeah, this is great software allright. *sigh*
--
Jesse Keating
Release Engineer: Fedora
Jesse,
If you had the hp daemons in, all you had to do was use CUPS to
install it. You don't need to use the HP toolkit at all .
--
Fedora Core 6 and proud
6:26 p.m.
On Wednesday 28 March 2007 19:20:29 Arthur Pemberton wrote:
Jesse,
If you had the hp daemons in, all you had to do was use CUPS to
install it. You don't need to use the HP toolkit at all .
"use cups". That's helpful. I use the print administration tool found in
my
menu. I don't care what backend that uses, I just want the printer to work.
I did add the printer via this backend, and being cluefull I know it uses
cups. However even after added and the daemons running and such, printing
working fine, hp-toolbox STILL can't find it at all, and thus I can't even
look at all those wizbang features you mentioned where possible.
--
Jesse Keating
Release Engineer: Fedora
7:08 p.m.
Jesse Keating <jkeating <at> redhat.com> writes:
"use cups". That's helpful. I use the print
administration tool found in my
menu. I don't care what backend that uses, I just want the printer to work.
I did add the printer via this backend, and being cluefull I know it uses
cups. However even after added and the daemons running and such, printing
working fine, hp-toolbox STILL can't find it at all, and thus I can't even
look at all those wizbang features you mentioned where possible.
HP USB printers can be addressed by 2 ways:
* the default CUPS usb:/ transport
* the hplip hp:/ transport
With the usb:/ transport, printing will work, but anything beyond that won't.
(In particular, hp-toolbox doesn't list the printer if it's configured with a
usb:/ URI.) So in system-config-printer, look at the device URI and make sure
it's set to a hp:/ transport, if it's not, use the Change... button, the hp:/
URI should be listed as one of the options there.
I hope this helps. With all the work you are doing in the Fedora Project to
help us users, I'd be glad if I was once of help to you. :-)
Kevin Kofler
7:40 p.m.
On Wednesday 28 March 2007 20:08:47 Kevin Kofler wrote:
HP USB printers can be addressed by 2 ways:
* the default CUPS usb:/ transport
* the hplip hp:/ transport
With the usb:/ transport, printing will work, but anything beyond that
won't. (In particular, hp-toolbox doesn't list the printer if it's
configured with a usb:/ URI.)
I guess my point here is that how is an end user supposed to know this, when
it isn't integrated correctly into the tool set we're putting out for
managing printers on the desktop.
--
Jesse Keating
Release Engineer: Fedora
8:04 p.m.
Jesse Keating <jkeating <at> redhat.com> writes:
I guess my point here is that how is an end user supposed to know
this, when
it isn't integrated correctly into the tool set we're putting out for
managing printers on the desktop.
Well, the end user is supposed to get the hp:/ URI automatically, at least
since hal-cups-utils-0.6.3-1:
* Tue Jan 02 2007 Tim Waugh <twaugh(a)redhat.com> 0.6.3-1
- 0.6.3:
- Applied all patches.
- Added syslogging.
- Use 'hp:' URIs when appropriate (bug #175555).
- Put PPD NickName in info line instead of just 'Added by HAL'.
- Don't add/remove new printer if one already exists with a matching URI.
The reason you didn't get the hp: URI is probably that hplip wasn't installed
when you plugged in the device.
Kevin Kofler
10:19 p.m.
On 3/28/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Wednesday 28 March 2007 20:08:47 Kevin Kofler wrote:
> HP USB printers can be addressed by 2 ways:
> * the default CUPS usb:/ transport
> * the hplip hp:/ transport
> With the usb:/ transport, printing will work, but anything beyond that
> won't. (In particular, hp-toolbox doesn't list the printer if it's
> configured with a usb:/ URI.)
I guess my point here is that how is an end user supposed to know this, when
it isn't integrated correctly into the tool set we're putting out for
managing printers on the desktop.
When I said CUPS, i meant that generally, not specially using your
browser on port 631. I was assuming that system-congig-printer
interacts with CUPS. WIth those assumptions in place, once the daemon
detects the printer, all you need to is add a printer, however you
feel comfortable, and it should appear in the list of addable
printers. No special magic. As I mentioned earler. All this happened
for me in FC6 automatically upon installtion.
--
Fedora Core 6 and proud
3:10 a.m.
Arthur Pemberton wrote:
On 3/28/07, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Wednesday 28 March 2007 20:08:47 Kevin Kofler wrote:
> > HP USB printers can be addressed by 2 ways:
> > * the default CUPS usb:/ transport
> > * the hplip hp:/ transport
> > With the usb:/ transport, printing will work, but anything beyond that
> > won't. (In particular, hp-toolbox doesn't list the printer if it's
> > configured with a usb:/ URI.)
>
> I guess my point here is that how is an end user supposed to know
> this, when
> it isn't integrated correctly into the tool set we're putting out for
> managing printers on the desktop.
When I said CUPS, i meant that generally, not specially using your
browser on port 631.
Going to http://localhost:631/, I can't help but notice that this page
contains the trademarked logo of ESP as well as advertisement for their
support and pro products :-)
7:35 p.m.
On 3/28/07, Jesse Keating <jkeating(a)redhat.com> wrote:
[...]
"use cups". That's helpful. I use the print
administration tool found in my
menu. I don't care what backend that uses, I just want the printer to work.
[...]
AFAIK, system-config-printer is (was?) broken, and I've heard the same
advice multiple times on the user-list: use CUPS. My memory ain't so
hot, but IIRC s-c-p should Just Work in F7. Or maybe that's just a
bad memory by now.
As a counterpoint to your horror story: I just dug a HP PSC 1210
(multifunction) out of the garbage this very afternoon. Took it home,
checked hplip was running, plugged it in, went to the CUPS interface
and added the HPLIP variant of the detected printer, and all is well
with the world - status, ink levels, scanning, etc.
...
I didn't even finish the reply before things went wonky :) Looks like
the color cart is fragged. Probably could have worked it out for
myself, but the hp-toolkit actually made it much easier. I understand
that the program is sub-par (being generous here), but I haven't used
anything like it in *nix that can communicate with the device on that
level.
FWIW, I'm +1 on getting HAL and friends to decide if hplip should be
activated, also +1 for putting the icon in the menu, and +1 for
pitching a bitch at HP to fix their mess. But since I don't do any
work around here, maybe my vote should be +0.02 / +0.02 / +0.02 :)
Chris
3:38 a.m.
Bernard Johnson wrote:
I do not disagree with the direction taken with CodecBuddy (this I
stated in my original email). I very much disagree with lack of
impartiality between vendors who are both supporting Linux.
You expressed some concerns with codec buddy itself which I hope I have
answered. Using that explanation to justify your argument to a desktop
icon for a unrelated package is bad form even when your argument is
right because it confuses two separate concerns. Please don't do that.
Regardless of your technical justifications, name calling and flaming a
fellow Fedora contributor with generalized and incorrect claims is not
constructive at all. Please don't do that either.
Rahul
6232
days inactive
6238
days old
109 comments
27 participants
participants (27)
-
Alan Cox -
Alfredo Ferrari -
Arthur Pemberton -
Bernard Johnson -
Chris Adams -
Chris Mohler -
Dan Horák -
David Zeuthen -
Denis Leroy -
drago01 -
Gianluca Sforna -
Hans de Goede -
Jeremy Katz -
Jesse Keating -
Josh Boyer -
Kevin Kofler -
Matthias Clasen -
Nicolas Mailhot -
Nicu Buculei -
Patrice Dumas -
Peter Gordon -
Rahul Sundaram -
Rex Dieter -
Simo Sorce -
Thomas M Steenholdt -
Tim Waugh -
Toshio Kuratomi