While I understand that as much as possible CentOS has remained compatible and almost a clone of RHE there is one area that really makes no sense in that. Some of the default RH paths have been an annoyance for over a decade. The whole rest of the Linux world puts FF in /opt. So why not CentOS? Pretty much any FF plugin you install like Flash you have to manually copy or write scripts to copy the updated versions or they don't get copied. This is a serious security risk for desktop users as Flash and other high exposure FF plugins are the primary gateway for user level attacks on a system. A user might well see Adobe flash has been updated, but in reality it hasn't. The RPM was downloaded and installed but the actual .so file went nowhere. It's not the .so file that FF is using that is for sure. Not until you actually copy it over too /usr/lib/firefox/plugins
Seriously of all the places in the world to drop Firefox why /usr/lib ? It's one of the most crowded and sensitive dirs on a Linux machine. Over the years I've had too answer the question about why this or that plugin still didn't work even though it was installed in RH/Fedora forums/list groups and other areas so many times it has become wearisome and every time I do a fresh install it annoys me to no end, though I eventually just go with the tarball version and ditch the rpm updates with FF and cease worrying about it.
Think about it, how many times have you had to direct somebody to where CentOS installs HTTP? Admittedly it's better to install from tarballs if your going to set up a production server as you'll want to do custom configurations that are not supported out of the box by anybody. Still a whole lot of test servers and people just experimenting with running Apache wind up highly confused as the docs on the web point them one place but CentOS/RH installs them somewhere else.
My suggestion is that CentOS break with RHE on the paths of certain apps like MySQL, Apache, Firefox and join the rest of the Linux community. Perhaps even RH will follow the lead of CentOS eventually thus making everybodies life a little less complicated when it comes to supporting/using these apps.
RH paths vrs rest of Linux
RH paths vrs rest of Linux
Hrrm, who puts firefox in /opt? Not FreeBSD, not ArchLinux.
Much of CentOS' value is its mimicry of how RH does things. To move firefox would be a bad idea, especially since many programs expect to find it.
The whole http and other files thing, well, it's one of the many things that make many people dislike RH, especially if they've used a BSD. (And other people probably think, wow, what a great idea! Why doesn't BSD due it that way?) However, like Windows, they're more or less ensconced, and due to the RH influence, many third party packages work with it, expecting the files in those places.
Much of CentOS' value is its mimicry of how RH does things. To move firefox would be a bad idea, especially since many programs expect to find it.
The whole http and other files thing, well, it's one of the many things that make many people dislike RH, especially if they've used a BSD. (And other people probably think, wow, what a great idea! Why doesn't BSD due it that way?) However, like Windows, they're more or less ensconced, and due to the RH influence, many third party packages work with it, expecting the files in those places.
Re: RH paths vrs rest of Linux
Haven't tried ArchLinux. Debian based distros do, pretty sure SUSE does or at least did. Same with Mandriva. Haven't tried either in a few years. It is the default destination for plugins (talking about /opt) and if your talking to FF support folks or on FF support forums they assume you've installed to /opt and suggest that you do so if you haven't.
I also go with tarballs for FF. Have for a long time since Fedora was my main distro and Fedora loved to keep older versions of it's distro on older versions of FF. So if I wanted FF 3.x I had to go to the tarballs. When I did installing to /opt made life so much easier. I'd use the Adoble RPMs and my flash was actually updated for example.
I never thought about there being much of a downstream for HTTP & MySQL products like that so you have a point there
Personally I prefer to create a web or DB partition and install there. All too easy to use up all space on / and I also like to use LVM for heavily hit Apache and database severs. I cringe at the idea of using LVM for /, have had too repair an LVM partition far too many times and if / is on an LVM partition that gets mighty messy. Using a separate partition for the AM part of LAMP makes it easier to employ disk quotas, ACL, chroots and makes backups a bit easier as well as making it much easier to reach dirs from a command line. It's just plain less typing. That's my personal preference which is obviously not the norm. Just advocating a bit of standardization between distros to make it easier on folks both admins and folks trying to help people. Instead of saying if your on x distro go here, or on this distro go there or telling the poor user to figure out what the path is for their distro. It also helps when I log in remotely to a machine and have no idea what distro. Instead of having to go to /etc and figuring out which distro I'm working with or doing a search to figure out where it's installed on that server I can go strait too it.
I also go with tarballs for FF. Have for a long time since Fedora was my main distro and Fedora loved to keep older versions of it's distro on older versions of FF. So if I wanted FF 3.x I had to go to the tarballs. When I did installing to /opt made life so much easier. I'd use the Adoble RPMs and my flash was actually updated for example.
I never thought about there being much of a downstream for HTTP & MySQL products like that so you have a point there
Personally I prefer to create a web or DB partition and install there. All too easy to use up all space on / and I also like to use LVM for heavily hit Apache and database severs. I cringe at the idea of using LVM for /, have had too repair an LVM partition far too many times and if / is on an LVM partition that gets mighty messy. Using a separate partition for the AM part of LAMP makes it easier to employ disk quotas, ACL, chroots and makes backups a bit easier as well as making it much easier to reach dirs from a command line. It's just plain less typing. That's my personal preference which is obviously not the norm. Just advocating a bit of standardization between distros to make it easier on folks both admins and folks trying to help people. Instead of saying if your on x distro go here, or on this distro go there or telling the poor user to figure out what the path is for their distro. It also helps when I log in remotely to a machine and have no idea what distro. Instead of having to go to /etc and figuring out which distro I'm working with or doing a search to figure out where it's installed on that server I can go strait too it.
-
hawaiian717
- Posts: 184
- Joined: 2009/01/30 19:58:25
- Location: California
Re: RH paths vrs rest of Linux
I think when people talk about installing to /opt, that's because that's what the Linux tarball from Mozilla does. Packages installed by a package management system, such as Yum, should be using /usr/bin. If Firefox or the plugins aren't flexible enough that they expect to be in /opt, that's a problem with the upstream product.
With respect to Flash specifically, it is very easy to keep up to date. Adobe maintains a Yum repository, just install it and do [b]yum install flash-plugin[/b], and it will be updated along with the rest of your system packages when you do a yum update, no special post install configuration or file moving required. RPMforge also maintains a flash-plugin package.
If CentOS starts moving things around so that files aren't in the same place as RHEL, it no longer maintains compatibility and they lose one of the biggest reasons people use it. If you think a file should be moved, talk to Red Hat and convince them to do it.
With respect to Flash specifically, it is very easy to keep up to date. Adobe maintains a Yum repository, just install it and do [b]yum install flash-plugin[/b], and it will be updated along with the rest of your system packages when you do a yum update, no special post install configuration or file moving required. RPMforge also maintains a flash-plugin package.
If CentOS starts moving things around so that files aren't in the same place as RHEL, it no longer maintains compatibility and they lose one of the biggest reasons people use it. If you think a file should be moved, talk to Red Hat and convince them to do it.