| |||||||||||||
Atime and btrfs: a bad combination?Atime and btrfs: a bad combination?Posted Jun 4, 2012 12:59 UTC (Mon) by nix (subscriber, #2304)In reply to: Atime and btrfs: a bad combination? by Yorick Parent article: Atime and btrfs: a bad combination?
And with every change you lose a bit of your userbase. Before you know it you end up with not very much userbase left at all.
(Log in to post comments)
Atime and btrfs: a bad combination? Posted Jun 4, 2012 14:50 UTC (Mon) by hummassa (subscriber, #307) [Link]
You made me smile.
One of our problems as developers is exactly that: one does not simply take features away. Lots of systems made me bury them exactly by trying to take "my" features (the ones I used and cared for and needed) away.
Atime and btrfs: a bad combination? Posted Jun 5, 2012 12:19 UTC (Tue) by Yorick (subscriber, #19241) [Link]
I'm going to assume you mean atime specifically, and not olcuc or anything else (you would have a hard time arguing for that one).
To remove old cruft, a good start is quarantine. Simply don't implement atime in new file systems (btrfs); people who need it for their business-critical fingerd can run UFS or ext2 or something else. The important part is that we don't let use of a bad feature to spread, since that is only going to make it harder to get rid of.
Instead of making code worse for everyone for the (dubious) benefit of a vocal minority of cavemen, deal with the problem head-on. Give them a chance to adapt - help them all you can - but set a firm date for when the coddling stops.
|
|||||||||||||