On Wed, 2007-11-14 at 17:52 -0500, Jon Masters wrote: > I vote for just not moving it. It's been around many times the lifetime > of FHS and other "standards", that themselves were based upon what > existed at their inception. If anything these "standards" should be > updated with occasional exceptions, based upon years of reality. As a systems administrator, I hate it when things get changed because it means more work for me. But I wouldn't even begrudge this move because it solves the bigger problem of "Gee, I need to install a new data server, but wheretf should I go to place my data files?! /var/lib/mysql? /var/www/html? /tftpboot? /var/lib/samba?" If it's going to be /var/lib/, then at the very least put that in the documentation somewhere. Because, currently, this is what I have in /var/lib/: alternatives cs dhclient dovecot hsqldb mlocate nfs random-seed samba setroubleshoot texmf webalizer asterisk dav dhcpd games logrotate.status mock ntp rpcbind scrollkeeper spamassassin tomcat5 xkb bluetooth dbus dhcpv6 hal misc multipath php rpm sepolgen stateless tor yum and I'm not sure what's supposed to be in them nor how the packages were split with that and /etc/<package> or /usr/share/<package> > Yeah, I know, this is a very conservative attitude for a change. I guess > we could just throw out the Linux kernel because it's also based on "30 > year old technology", but it seems to work well for most of us. Could we please stop using inaccurate analogies? Asking that we throw out the Linux kernel is like asking to throw out tftp-server and not at all like moving data subdirectories. If you must bring in the kernel, then it would be akin to changing /proc semantics or adding /dev/shm (which has already happened). One of the reasons why there has to be a ton of books on Unix system administration is precisely because a lot of things in the past could only be gleaned by going through tons of documentation. Believe me, I can see the stark contrast between then and now ... specifically when it comes to service configuration. Before I had to trundle through loads of docs just to find config files. Now it's an easy guess with checking "rpm -ql <package>" for /etc/ files. Shared objects files also seem to have come under standardization with most of the native elf shared objects going into /usr/lib(64)/. It's a little bit different for server data files, though. Mail spool, proxy caches, etc. have gotten a little tamer, but there's always room for improvement. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
