also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.12.18.1241 +0100]:
> For a transitional period, I suggest you create $HOME/etc, move
> your dotfiles there and symlink them back. Then try to put your
> $HOME in CVS or use it on a system that still thinks that the
> status-quo is perfectly fine.
I have been doing so for years. What am I to watch out for?
> Inode quotas. The number of files (that includes directories and
> symlinks) is limited, and for my work there, I need quite a few
> files, so I'm already near my limit. Were I forced to place
> a hundred symlinks, I'd overrun my quota. That means, that either
> I can't work on that box, or I need to change my habits, and stop
> managing my $HOME in CVS.
I do not consider that an argument against my proposal, rather an
argument for your system administrators to upgrade hardware and
policy.
We are not kicking KDE 3 out of Debian because I still have some
systems with 200 Mb harddrives.
> > As another post suggested, the standard, if it's implemented, should be
> > managed on a package-by-package basis. Which if ported back upstream
> > means that cross-distro compatibility should be maximized. Not wholly
> > problem-free, but headed there.
>
> It should be done upstream first, if done at all. And in such a way,
> that the old location is searched first, then the new one.
You are failing to acknowledge Debian's position wrt to innovation.
Upstream will change after the FHS changed. The FHS will change
after Debian showed them the benefits. So Debian has to work on it
(possibly with upstream).
also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.12.18.1236 +0100]:
> Especially if that's only on Debian, and the rest of the world is
> still putting stuff into $HOME... (that is, if there's a way for
> migration, it needs to start with persuading upstream authors that
> it needs to be done. Until a considerable amount of software
> supports both locations, there's no chance the opposing voices
> will go silent)
Catch 22. It's never going to happen unless we do it.
So I urge you to please stop holding on to the "it's never been done
before" and "but it works, why change it" excuses and think and
discuss about the technical pros and cons instead.
also sprach Gergely Nagy <algernon@bonehunter.rulez.org> [2004.12.19.0044 +0100]:
> find and xargs can help with that. Or a file manager (/me pats
> dired-mode)
Why not patch the kernel stat() while you're at it. Please stay on
the practical side.
> > What's more important than raw implmentation is expressing a preference
> > and getting applications developers to start following it. Everything
> > else is bloviating.
>
> My preference (both as a user and upstream for a few small utilities) is
> to leave everything as-is until I have more files in ~/etc than in plain
> old $HOME.
"men who say it cannot be done should not interrupt men doing it."
-- old chinese proverb
if you are a follower, then please do so and don't stand in the way
of leaders.
I am not suggesting that ~/etc must happen. I am trying to argue for
it. You have some valid arguments along the lines of "never touch
a running system". If we would cling to that, there would be no
innovation, and I would not see a point to releasing a new stable in
the first place.
also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2004.12.18.1521 +0100]:
> If symlinks were used, it will break with editors like Emacs that
> snap links, or with programs that rewrite/update their conffiles.
Those should be fixed instead. Emacs is a major pain for writing
into a new inode.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, user, and author
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
Attachment:
signature.asc
Description: Digital signature