I am using NFS (v4) home directories. The server is running Fedora 16;
the client is running Fedora 17. Recently, when running Evolution on
the client, I find that Evolution becomes completely unresponsive if I
attempt to compose a message. (It freezes up before showing the new
message window.) When I look at the process in the GNOME system monitor,
the evolution process' "Waiting Channel" is alternating between
"nfs_wait_bit_killable" and "rpc_wait_bit_killable".
Has anyone else using NFS-mounted home directories on F17 observed this
sort of thing?
Trying to start a netinstall with a ks file behind a proxy without luck.
url --url="http://.../" --proxy=http://10.0.0.4:80
repo --name=testing --baseurl="http://.../" --proxy=http://10.0.0.4:80
If I change consoles and export a http_proxy=http://10.0.0.4:80 I can wget anything
Anyone know the trick here?
On fedora 16 if I type "reboot" in a terminal, there is a
7 second delay from when I hit enter to when shutdown messages
start scrolling on my screen (I have rhgb turned off).
On fedora 17 if I type "reboot" in a terminal, there is a
1 minute and 37 second delay between enter and shutdown
Anyone know what the heck is happening in those extra
Dne Ne 29. dubna 2012 19:03:18, Máirín Duffy napsal(a):
> On Sun, 2012-04-29 at 15:25 +0200, Karel Volný wrote:
> > So, feel free to join me with the moment of silence for the
> > good old GIMP that is just getting buried.
> If you could tone down the snark and indignation  you might
> have a halfway decent bug report on the export tool there,
> although in any case sending it to friday-list(a)redhat.com
> won't do much good.
>  This timbre of feedback is part of the reason why I don't
> like working on desktop apps.
it is a problem of action-reaction leading to a loop which
usually ends by someone getting so angry to completely give up
trying making things better ...
basically, the developers' impact on users is
1. fixing bugs
2. creating new useful features
3. creating new unuseful features
4. breaking existing things because of new unuseful features
x. many more options
in case 1. and 2., the users are happy and give positive feedback
in case 3., sometimes the users get upset if those features get
into their way, but generally they tolerate it - "just don't use
it", "I'd be happier if they spent time fixing bugs instead but
hey that's opensource, I don't pay them ..."
in case 4. the users get upset, more or less, but *always* upset
now someone writes a rant ...
then the developers get upset about the feedback and tell the
user he has no right to talk that way
then the users get more upset that the developers don't listen to
the users and that they are arrogant
now the developers are getting really angry because in their eyes
it was the user who was arrogant, so tactless to criticise
something that "he doesn't understand", and that he was so
impolite to say that the developers don't handle the case well
... see the pattern here?
the problem is that you really have to go one step back - if an
user is doing harm to developers, it is not out of nowhere, but
as a reaction to harm caused to him by the developers
I hope there doesn't exist one more step before like "in previous
iteration, users were bad to us, so let's break some feature to
do harm to them" :-)
as for my email, this wasn't meant as a serious criticism (hey, I
really do *not* say "GIMP sucks") but rather a topic to think
about, hence the selection of the target list, with a copy to
testlist so that QA can get some inspiration for filing bugs (see
I apologise for any possible offense caused by me being too much
> Re: the EXIF rotation dialog, I'm guessing you're working with
> a fresh install / blew away your .gimp-2.x directory because
> I've only ever seen that dialog once long ago: if you tell it
> to always rotate based on EXIF and not show it again it will
> do as you say. It would be a reasonable bug report / feature
> request to ask for a preview of what each button would do in
> the dialog so you'd know visually what effect taking the
> action would have if it's not clear from the text.
the preview wouldn't be needed if it'd clearly state "exif
orientation" or "file orientation" ... what is "standard"?
(now I see the dialogue as a whole is a bit more comprehensible
in English than in Czech ...)
> If you don't want to file what appears to be a very valid set
> of bugs in the new export tool (not remembering the last set
> of JPG export settings, registering unsaved changes on the XCF
> when there are none.) I suggest using an app like Shotwell for
> minor edits to images.
um, sorry, no
I have more than enough bugs reported (should watch them, retest,
provide details ...) for things that I use daily, I'm not
interested (I don't have the time) doing this for an application
which I use once per month and which I'm currently seeking
replacement for ...
(thanks for the suggestion for Shotwell, but GIMP was one of the
last GTK based things I'm using and I have some negative bias
towards the others ... now let's hope that Wireshark won't get
any worse :-))
> The reason exporting to file formats like JPG and PNG via
> Export rather than Save makes sense to me is because of this
yep, it makes sense to you
that is why I'm talking about incompatible way of thinking
and I'm perfectly okay with the fact that someone wants to do
things in another way than me - diversity is good (plus I'm often
mistaken, so not doing things like me is really better ;-))
what saddens me is that the other way of thinking is forced on me
- I was quite happy in this regard with the previous version of
GIMP but now I have to find something more suitable for me ...
I really don't like this practice of "overtaking" projects (or
how to call that) - there is something that is good enough for
zillions of users, now someone comes and says this must be
changed and it is changed, leaving the users disappointed
this seems to me less than optimal ... if there is some new idea,
let it live along the old one and see which one is better - if
most of the users voluntarily move to the new one then let the
old one slowly die, as the users are moving away, but if the
users stick with the old one, they do not find the new one
better, then let die the new one and don't push it to everyone by
force (and keep both if users like both)
> I'm going to LGM next week so I'll try to show the bugs you
> pointed out here to the Gimp folks there if I get the chance
> to speak with them, but it would definitely be helpful for you
> to file bug reports as well if you are interested.
thanks, I appreciate that - when I've provided details about the
problems I was hoping that someone may use it as an inspiration;
I, personally, am no longer interested, see above
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
:: "Never attribute to malice what can
:: easily be explained by stupidity."
did somebody try to play a video DVD (VIDEO_TS) by *gmplayer*? I'm
successful in playing the DVD with *"mplayer /dev/sr0"* (picture is
shown), but using gmplayer with /dev/sr0 as device only plays sound :-(
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
I do not have LibreOffice installed on my system, I have Apache
OpenOffice 3.4 RC1.
However, launching the system updater notifies me that there is an
update available for URE-Runtime (a component of LibreOffice) and
install such update.
If this breaks Apache OpenOffice 3.4 who's to blame?.