Kevin Kofler wrote:
> Roberto Ragusa wrote:
>> So it now runs F10 with KDE 3.5.10 from F8 updates.
>
> These packages are NO LONGER UPDATED. And running F8 packages on F9 or F10
> has always been asking for trouble, especially for software like KDE with a
> lot of dependencies.
Kevin, the packages are no longer updated, that's true.
And mixing packages can cause troubles, that's also true;
but I tried doing it, and I can say I did not find any
issue.
There are dependencies, but the rpm/yum machinery did
the job perfectly; the compat rpm I had to rebuild can be counted
with only one hand.
>> As for F8->F9, some compatibility rpms had to be compiled
>> with little modifications to the spec files.
>
> Which means that your libraries are also NO LONGER UPDATED.
>
> You're just asking for some security hole to go unfixed and your machine to
> get broken into.
The security of my machine is important and I perfectly know
that updating packages is good practice.
But a general rule of good behavior should not be an absolute
dogma.
I'm perfectly aware that by freezing packages at a fixed
update I'm assuming security risks, but after reasonable
evaluation, I can decide to take the risks.
We are not talking about a popular site using an ancient apache
binary on a 2.6.0 kernel. This is a laptop, no services offered
externally, good firewall rules, one (not-newbie) user.
Where are the risks? Let's say someone sends me a malicious
TIFF pic to exploit a buffer overflow in libtiff, and I use one
KDE app linked to the unpatched lib,... How big is the probability
that there is such a vulnerability? How big is the probability
that someone will want to attack me? How big is the probability
that I will use the vulnerable app and not, let's say, the fully
patched GIMP app?
My estimation of all this leads me to a simple conclusion: I can
afford the risk.
There is no ancient libtiff (just an example), and I'm pretty
sure the biggest risk is in openssl098b, which my KDE3 is using
(libssl.so.6). So, maybe something will be discovered to be wrong
with the certificate management, and someone will steal my
bank password and steal all my money.
But I don't use konqueror for banking, and Firefox is updated.
And I use a specific Unix user for that Firefox instance.
And I will not easily click on "please confirm your data" emails.
So, at the end of the day, I take the risk.
Life is always trading risks for convenience. Intelligently.
>> I'm not writing all the details here now, but if anyone is
>> interested, I can do it (and publish the spec files if
>> someone wants to try).
>
> Please don't. We don't want our users to run unsupported software, and we
> especially don't want you to make it easy for them to do that.
Your point of view is perfectly understandable.
You want to stress the importance of having updates and you want
to discourage people messing with their system.
(we are on the user ML, so the message had to be stronger than
what would have been on the dev ML)
But I ask you to reread exactly what you have written, please.
You said you don't want me to help people wanting to do this.
Your intentions are good, but that position is quite surprising
in a "free speech" software world.
Ability to modify everything? User collaboration? Free knowledge?
You are asking me to "not make it easy" for others.
I can accept the "it is not a good idea", I can accept the
"you will not receive support",... but aren't you going too far
with that position? It should be also clarified what "we" means.
I remember that there was a "time bomb" idea discussed in the
past: when the distro is out of support, it should not run
(for security), or it should strongly harass the user about
how he is doing something dangerous. The "let the user do
what they want" approach won.
Let me make another example.
Binary kernel modules are evil and discouraged, I know.
But I have to run the f*****g Nvidia binary driver and
the rpm from rpmfusion is helping me to do it less painfully.
I tried to avoid the damned driver; I can live without
hw opengl (sorry, googleearth), without xv (sorry, mplayer
rescaler), but I can not live without power management:
the vesa driver increases the power consumption by 10W.
So, after consideration, I decided to run the Nvidia driver.
And it is crap. Disk hibernation (tuxonice) becomes unreliable
(tried every possible trick). So I have to use suspend to ram.
It's the best compromise for me. My work session is important,
my battery duration is important, so I have to do that.
Thanks to rpmfusion for helping me to cope with the stupid
Nvidia hostility towards me.
>> F10 is great, but KDE 4 is still not able to convince me to
>> leave KDE 3 behind.
>
> But you'll have to get used to KDE 4 sooner or later. Better sooner (how
> about NOW? KDE 3 is no longer supported in Fedora). KDE 3 is not going to
> get updated forever (in fact the F8 packages you're using are already no
> longer updated) and at some point the old packages will just stop working.
> (They already do, that's why you have to build old libs for them as well,
> but that's going to stop working at some point as well.)
I will move to KDE4, sooner or later. Sure. I love KDE and I'm
sure KDE4 will be a great desktop.
But I tried it, and it is not suitable to me yet.
I can relearn things.
I can reconfigure my stuff (I do not want wasted pixels, so the
theme is important, I have to retune every font size, icon size
and many other details which make the difference between a usable
desktop and a mess).
Spending a day or two reconfiguring is not a problem.
But I see that things are missing in KDE4.
And sometimes the word "stability" pops up. Having to cite that
word is not acceptable to me.
My screen is 1920x1200, with 16 virtual desktops, and they
sometimes are apparently not enough. Multiple instances
of Firefox, Thunderbird, pidgin, openoffice, java apps, dozens of
konsole and konqueror windows.
Just look at this, nagios is angry at me.
Jan 16 21:11:22 localhost nagios: SERVICE NOTIFICATION: nagiosadmin;localhost;Current User
s;CRITICAL;notify-service-by-email;USERS CRITICAL - 67 users currently logged in
Jan 16 21:25:12 localhost nagios: SERVICE NOTIFICATION: nagiosadmin;localhost;Total Proces
ses;WARNING;notify-service-by-email;PROCS WARNING: 327 processes with STATE = RSZDT
Do not tell me that I'm using my machine in the wrong way.
("no one will never need more than 4 windows" :-) )
I need that, my productivity needs that.
So I need a stable desktop.
A fast desktop.
A powerful desktop.
Drag and drop from konqueror (ftp://) to kate is fundamental to me.
Double click on a file (ftp://) to enter a tar.gz and then enter a zip
and then display a jpeg is important to me.
Things like that. KDE4 has some of them, but is still missing things.
I have a rawhide installation and experiment with KDE4 every now and then.
It is not good for me yet. I'm impatient to switch, but I know I can't yet.
You are right, making the old F8 KDE to run on F10 needs time.
And there is no update stream for F8 anymore.
And one day the KDE project will stop updating KDE3.
But I have to stay with KDE3 at the moment.
During the time interval between sooner and later, I need a high quality
desktop to work with. Still no alternatives to KDE3.
Sorry for the additional long rant on KDE3/KDE4.
Kevin, I know that you are a very active KDE supporter.
Thank you really so much for your work.
I also know that KDE4 will improve only if users try it,
report bugs, report wanted features and validate fixes.
An egoistical reasoning for me could be: "I managed to run
KDE3 and that's good for me. It is good for me if others have to
run KDE4, suffer the problems and push to have them fixed, so
that I can switch too".
Then I thought that sharing my approach could be useful
to some other guy, who has just a little less technical ability
than me.
Is this free software? Aren't we all here to help and be helped?
This is the only reason I sent the original mail.
Thank you for your time.
I appreciate what you do for KDE.
--
Roberto Ragusa mail at robertoragusa.it
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
