Re: KDE is now broken (Fwd: Heads-up: KDE4 hitting testing tonight (UTC) )



On Mon, May 25, 2009 at 01:17:16PM -0500, Boyd Stephen Smith Jr. wrote:
In <20090525163904.GB5158@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, lee wrote:
On Sun, May 24, 2009 at 03:28:50PM -0500, Boyd Stephen Smith Jr. wrote:
In <20090524145214.GA16426@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, lee wrote:
I
don't want to run an akonadi server either, whatever that is.
Oh, then you don't want to run those parts of KDE; They require a
connection to an Akonadi server. They've been scheduled to since before
KDE 4.0 was available.
Maybe not. I'd be fine without them, if it would work without --- but
it doesn't.

I said it before, and I'll say it again: That is just not true. I was careful
in my package selection and I have a working KDE 4.2 (including my must-have
kmail) and I do not have a mysql server installed.

KDE 4.2 can work without Akonadi, with a minimum of fuss.

It is true, just a matter of fact. KDE is broken on my computer since
the last update I did. It doesn't matter if it's possible to get it to
work without a mysql server. I'm not going to re-install everything to
try to make it work without.

Careful package selection was a good thing until a some years ago; now
there are too many packages and dependencies to keep that up. You
probably still can do that if you're willing to spend a week or two or
more to read all the descriptions, check the dependencies and maybe
implement your own, but it's no longer practically feasible.

You could as well assume that the result of careful package selection
has been that KDE is now broken because I refused to install the mysql
server.

Not if the file format was public. I can understanding not using a format
that can't be processed without a particular piece of software, but the
on- disk format used by MySQL is public information. You don't have to
use MySQL to access. You can write your own software or pay someone to
write the software for you without the blessing or control of MySQL.
Where do you find the needed information in 20 years?

On your HD, or wherever you chose to store it. If the information is public
you can copy it to any location and translate it to any form you need to.

Yeah, if you want to make a full time job out of tracking all changes
made over time to the storage formats of all software you're using to
store something and if you have an unlimited amount of storage space
and backup space available and if you can store and maintain all the
information (including keeping it in readable form) over at least 30
years, that might be a possibility. But it isn't practically feasible.

And what if you
want to access the stored information but you don't want to wait a
year or two before you were eventually able to figure out what format
was used to store it and to create software allowing you to retrieve
the information?

Use the old software. It might not run on the latest release of Debian, but
it should run on whatever version you had before. Older releases are
maintained in the archive, and you can archive whatever you need yourself if
you don't want to depend on the Debian infrastructure.

No one is forced to upgrade, but support does dwindle for a product over time.

Where do you find the old software? How do you get it to run on
contemporary hardware? Or do you suggest to rent old hardware from a
museum to install 15 or 20 year old software on it to make your data
accessible? Or are you suggesting to rent storage space to pile up old
hardware? That would require you to buy everything new, including hard
disks, for example, when upgrading your hardware, and that's something
I never did. And who guarantees that 30 year old hardware you kept in
storage will still work when you need it?

And BTW, it's not only wasting resources to have a mysql server
installed that you don't need and don't use, it's also about making
things more complicated and time consuming when you have a mysql
server that eventually needs to be adminstered and that you eventually
have to figure out a way to make backups for?

IIRC, Akonadi uses the "embeded" MySQL by default. It stores data and
settings in your $HOME so it would be naturally included in any backup. It
also is fully administered by the Akonadi server itself.

Then why do the dependencies require that a mysql server be installed?

What if you use
stable and from one distribution to another, or the one after the
next, they change something about mysql and you suddenly find yourself
with the problem of having to somehow convert your data to be able to
use it with the new mysql version?

Data translation issues can, have, and will happen even if "plain
text" files.

After a very long time maybe, yes. I haven't said they solve the
problem or that I had a solution. The only thing I can do is to use
something that appears to be very likeley still easily readable after
a long time. I can still read text files that are 15 years old. Maybe
I can't read them anymore in another 15 or 20 years, but chances are
that I can. And the chances to still be able to read a text file ---
without having to come up with enormous, not practically feasible
efforts to do so --- in another 20 years seem much greater to me than
being able to read mysql databases that are then 35 years old.

KDE generally hides this from the user. For example, the KDE configuration
API allows the developer to register a translation that is required (maybe
something simple like a configuration key rename) and what translations it
depends on. The configuration file will contain a list of the translations
already applied to it and the API will "automatically" apply whatever is
needed to update the file.

These same issues can be hidden when using RDBMS backed, but the translations
are usually much faster.

Both of these won't be human readable, plain text files. Try to read
your current kde configuration in 35 years, or try to read your data
from the the RDBMS you're currently using in 35 years. You'll find
that it won't be easy.

Can you still read all the different formats 5.25" floppies came in?
Can you still read tape cards or punched tapes? Magnetic tapes? It's
not yet impossible, but I can't read 3.5" floppies anymore since years
because I don't have the hardware needed for that. Try to read a CD or
DVD you burn today in 30 years. Even if you keep all the hard- and
software, what do you do if the hardware doesn't work anymore after
such a long time? It will be pretty much irreplaceable if you can't
find a museum to help you out or if you don't pay someone to build it
for you.

Now I already can't read the files I created with software I used when
I was still using OS/2 less than 15 years ago. But back then, I
converted what I wanted to keep into a format that, back then,
appeared likely to be readable in many years, and only because I did
that I can still read them.

Maybe software developers need to wake up and find a solution for
keeping data readable and useable for long periods of time --- if
that's possible at all.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx



Relevant Pages

  • Re: KDE is now broken (Fwd: Heads-up: KDE4 hitting testing tonight (UTC) )
    ... don't want to run an akonadi server either, ... KDE 4.0 was available. ... on- disk format used by MySQL is public information. ... The configuration file will contain a list of the translations ...
    (Debian-User)
  • Re: KDE 4.2 requires local MySQL Server
    ... And KDE cannot be updated to version 4.2 without updating akonadi ... KDE 4.2 requires MySQL (server) to be installed. ...
    (Fedora)
  • Re: [kde] Akonadi server will not start
    ... Akonadi Server Self-Test Report ... Akonadi server configuration and was found on your system. ... MySQL is started when I boot up. ...
    (KDE)
  • Re: multi-master with mysql backend
    ... All DNS servers are slaves to a single, ... being assigned to loopback interface on the server. ... I'd keep two copies of the BIND config, one that has all the zones as "master", and one that has all the zones as "slave". ... No need for rsync or mysql, BIND replication does all the work for you. ...
    (comp.protocols.dns.bind)
  • Re: multi-master with mysql backend
    ... Subject: multi-master with mysql backend ... All DNS servers are slaves to a single, ... being assigned to loopback interface on the server. ... No need for rsync or mysql, BIND replication does all the work for you. ...
    (comp.protocols.dns.bind)