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@cat.rubenette.is-a-geek.com>, lee wrote:
> >On Sun, May 24, 2009 at 03:28:50PM -0500, Boyd Stephen Smith Jr. wrote:
> >> In <[🔎] 20090524145214.GA16426@cat.rubenette.is-a-geek.com>, 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.
Reply to: