Re: Bug#282067: yes!
On Tue, 2004-12-21 at 12:35 +0100, martin f krafft wrote:
> also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.12.21.1130 +0100]:
> > CVS doesn't like symlinks. So if I have ~/etc/yada.conf, and ~/.yadarc
> > is a symlink to that, CVS will probably think they are two different
> > files.
>
> which is why you keep ~/etc in CVS and maintain the symlinks
> manually (I have a symlinks.d in each directory with files in it
> describing the symlinks, and a cronjob that takes care of enacting
> them.
And while the transition is ongoing, while I have files in both? I move
a file, and lose history. Unless I do a repo-copy, which I won't.
> > About using it on systems that do not approve of the migration:
> > one has to symlink files back, which gets you a cluttered $HOME
> > AND an ~/etc. Worst of both worlds, thankyouverymuch.
>
> Works very well and allows you to simply filter all links from ~.
And kinda defeauts the purpose, since my $HOME will be as cluttered as
before. Especially if I use systems which I know for sure, will never
ever migrate while I'm alive. (On the `why touch something that works'
basis)
> > > I do not consider that an argument against my proposal, rather
> > > an argument for your system administrators to upgrade hardware
> > > and policy.
> >
> > Not an option. The system has been in used for as far back as
> > I can remember and it works flawlessly, apart from this little
> > annoyance I can handle fine right now. There's no reason to
> > upgrade neither hardware, nor software. Not to mention that would
> > cost more than the owners are willing to spend, for no financial
> > gain.
>
> The point is more that I see no reason why one should honour
> reluctance to accomodate new requirements as an argument against
> potential innovation. We do not cap other cars at 60 km/h just
> because your ancient Bentley does not do more (albeit being
> beautiful and flawless).
Because this system being old does not slow or cripple anyone, it does
no harm. It is there, has been there, works and just because there's
some other new nifty thing, it won't be upgraded. If it starts to break,
or cause trouble - yes. Until then, it's fine there.
> > > We are not kicking KDE 3 out of Debian because I still have some
> > > systems with 200 Mb harddrives.
> >
> > Nor do we have to install it at all, while dotfile migration wouldn't be
> > a choice, were your proposal accepted. Installing KDE or not, is a
> > choice.
>
> Fair enough, bad comparison.
>
> Anyway, to do dotfile migration, we need to simply get a critical
> mass of upstreams to change.
Not only that. You need a critical mass of systems to be upgraded to the
changed software at roughly the same time, otherwise you get
interoperability problems when you try to place the config files to
their new location, when using an old version.
For example, lets imagine a university, with a fair number of computers.
They have a policy on running Debian testing. Now, there are some
different computers in the lab there, some AIX boxen, some Suns and even
an old and rusy Ultrix. And a DEC OSF-1 hidden in one corner. All these
machines were set up back then, in the Old Age, so they provide the same
look: the same fvwm runs on them. One sits down at any of those boxen,
and it works as any other. Maybe slower, maybe at a smaller resolution,
but those are details noone really cares about.
Now, for the ease of system administration, and to confuse users less,
$HOMEs are shared via NFS. J. Random user has a habit of sitting down to
the computer next to the window, so he can stare out. That happens to be
a shiny `new' Pentium 3, running Debian testing. At class, he learns to
customise Emacs, as that is the standard editor there, for ages ago, one
guy wrote a fantastic lisp package for it that every match student must
use, because that's what the policy is. All good and joyful, one day he
finds the computer broke - things like that happen all the time - so he
sits down to another, which happens to be a shiny and new UltraSparc
running some version of SunOS, which happens to have software installed
that searches for ~/.emacs, instead of ~/etc/emacs. Poor J Random User
is unhappy, and goes to complain to the admins that he lost his configs.
Then, the admins, who are usually only working on the Debian boxen, find
out that *ouch*, those config files got moved. What a pity.
What do they do? Recompile all software on the old boxen, on the Suns,
on the AIX, on the Suns and the OSF-1? No way in hell. They either
educate their users, or switch to a distribution or system that
interoperates well with the others. Reinstalling a hundred somewhat
similar systems in bulk is a no-brainer these days, they can do that in
a weekend or so at most. Recompiling software for old systems that are
still in use, and verifying that they work, that is a no-go.
You might say they should've known about the migration. Suppose they
don't. They have enough trouble, and can barely keep up with
security-announce alone, so they're on no other lists.
Or a more likely case, one lab is using Debian testing, because the lab
admin prefers that, the other is using NetBSD, because he prefers that.
They are good friends and worked together so their users don't notice
the difference. Give them dotfile migration and hell freezes over, and
blood tears they will cry.
So, back to my original point - if there's not a criticall mass of users
doing the migration with the critical mass of upstreams, the result
would be serious interoperability problems.
> Then we need no symlinks and eventually
> it will all take its natural course. If by the end there are only
> few offenders, we can then use symlinks while beating them over the
> head with cluesticks.
Again, you assume that most will want to co-operate. Both developers and
users. When you're trying to break a tradition, that roots back to the
early days of UNIX, that is unlikely to happen.
Some will come and find flaws in the outlined migration paths, some will
oppose the proposal on philosophical grounds, and some only because they
don't like you or Debian. I'm pretty sure quite a few upstreams fall
into one of those categories, which kinda makes it hard to achieve a
critical mass.
Then again, the main problem with achieving critical mass is not the
people. It is interoperability problems during the time criticall mass
is not achieved. Lets say we have J Random Student, who gets fascinated
by this Unix thing at his university. The university is running some
version of Linux. J Random Student goes and installs the same version on
his laptop. Lets suppose it was Debian stable. He then, discovers that
hey! there is this testing thing, with so much good stuff like new
versions of GNOME, X.Org and all kinds of good stuff! Eyecandy for the
masses! Wants, wants, wants! Eyecandy is good, people like it. So he
goes and upgrade his laptop to testing. Then, goes back to university,
which provides wireless access to its internal network for students,
sets up the connection with a few clicks, mounts his $HOME from the uni
network, starts to work, and is happy, everything works (since the files
were moved and automatically symlinked back). Now, he discovers there is
this new program that looks handy, so starts it, configures it and
stuff, and he is happy. Later, when he is in the computer lab for some
reason (writing some test or so), he wants to use the same program, on a
Debian stable system. And lo! Where have all the customisations gone?!
The program on his laptop placed those to the new location, and the old
software doesn't find it, that is what happened.
Of course, the program could be made so that even if it creates a new
file, and not just moves the old one, it creates a symlink. But then...
Who will delete the symlink? How will we know it can be deleted safely?
Not the program, that's sure. And J. Random Student doesn't, either. He
just uses a GUI to configure the tools he uses. He has a cluttered
$HOME, a more cluttered one, a less portable one. It's a good thing he
doesn't ever see dotfiles, because his filemanager doesn't show them at
all.
And again, those who are bothered to see their home cluttered, can
already implement ways to make it less so. Those who don't care,
shouldn't be subjected to problems, because some people want to change
and ages old tradition, for no technical reason.
> > > Catch 22. It's never going to happen unless we do it.
> >
> > Yes. It won't, unless you can persuade a large number of
> > developers that what they've been doing wrt dotfiles in the past
> > few years was a bad idea to begin with. I do not see any chance of
> > success, to be honest.
>
> Your glass is half empty when it could be half full. It's not that
> they have been doing anything wrong, but they may be able to do it
> better.
If it is not wrong, why change it? It has worked so far, hasn't it? What
is the benefit of moving to ~/etc? Apart from less clutter in $HOME,
which is not so strong an argument for such a great task as migrating
dotfiles.
Don't get me wrong, I would have been happy if dotfiles were placed in
my $HOME in a more structured manner (and if they resembled some unified
syntax too! *sigh*)... but it's too late to change that.
> > - Symlink the config file automatically: this would either move the
> > configfile to the new location and symlink it back to the old one, or
> > the other way around.
> > Pros: Easy migration if nothing breaks and does not break $HOME-in-CVS
> > if done right.
> > Cons: Clutters $HOME even more than it was before, since the old file
> > must remain in place for $HOME-in-CVS to remain working reliably. And
> > many users will not notice the migration, will end up with a more
> > cluttered home, and the purpose is defeated. This is out too..
>
> The more cluttered $HOME now contains precisely one additional
> entry.
Pardon? It contains as many symlinks as many files have been moved to
~/etc, until ALL systems one uses are migrated. Which won't be soon. A
decade long migration is a pain, no sane user would want to subjected
to. (Think about shared networks, not isolated users. Migrating an
isolated user is easy. Migrating a shared, multi-OS network is not)
--
Gergely Nagy
Reply to: