Yes, but its not standard (according to the LSB). That's why the links from the correct location to the incorrect one now exist. I agree that links are good, but symlinks don't solve every problem, and RH have indicated they will hopefully move to the correct location in future.
If I'm writing software for Linux, I should create it in line with the Linux standard base, which specifies RPM (currently RPM 3) packaging. All LSB distro's should allow me to install that package.
Yes, Debian includes RPM (so does Slackware) but it doesn't track dependencies on those systems, which makes it pretty worthless.
Agreed. The RPM situation on Debian needs to be improved. Adding some of.Debs more useful features to RPM might assist this. But currently, I know I wouldn't like to rely on the LSB (and hence RPM) to install anything rmeotely important on a Debian box.
I still see making an RPM here as a redundant step.
This is useful because it allows preple installin that package to
Install in a uniform, non interactive way. This way you can install your package as part of a automated update or rollout to your machines. At my workplace, `apt-get install cybersource-workstation' pulls down every RPM package needed to do work on a cyber workstation, plus config files for printers and similar items, and installs a couple of hundred pieces software automatically across each machine. Doing this without packaging is difficult.
Intelligently deal with configuration files during upgrades
Install, uninstall, and more importantly be queried using the same mechanism, so other admins know what you've done (this can be saved with a lot of documentation, but you'd spend more time documenting the machine than adminning it).
Uninstall the package cleanly (make uninstall is unforunately rare)
But when someone comes up with an "autospec" "autorpm" program which figures out everything to make the RPM file so it becomes as trivial to make it as to install it, I might be more interested.
Its nice that you're open minded. RPM pretty much already comes with something like that already, which automatically adds the libraries an application relies on to its dependencies when creating the package. Besides that, most apps generally only have a couple of dependencies anyway, and they're quite simple ("my printing config needs lpr installed, what package own lpr, add that package to the dependencies list" - its pretty easy).
Maybe that explains why software is so easy to install, uninstall, and update on Debian... its because none of it really exists.
Asides from the lack of logic in yoru sarcasm there (where did I indictae that there aren't any apps for Debian), there's very little difference in ease of use installing software on either Deb or RPM based distro's. Many Debian folk seem unaware that tools like up2date, urmpi and apt exist and come with most RPM based linux distributions. Personally, I apt-get update my Red Hat 7.2 machine from Freshrpms each day.
Lets face it, the LSB is not an objective standard but a crappy attempt at a standard that has succeeded in nothing more than giving Redhat a supposed stamp of approval as not only the defacto Linux standard, but the dejure (sic) Linux standard.
The standard itself seems to speak otherwise.
Red Hat has had to move the location of its initscripts and documentation
The same way suse has also had to move its initscripts and start thinking about not using/opt for distribution packages.
Red Hat didn't join the LSB for two years, while most of these decisions were made, precisely to avoid the exact claims your levelling against it - that its market share is having an undue influence on the LSB. Most of the LSB was built by other distributions, including Debian, who have been doing the LSB for much longer than Red Hat has.
Good standards codify existing practices - the decision to use RPM as a packaging standard reflects the popularity of this packaging system, and according to most (eg, Netcraft's surveys) the vast majority of Linux systems use some kind of RPM based distribution (and this would still be the case without Red Hat). Seeing as there's very little but minor differences between the different packaging systems (apparently RPMs package signing and verification is better than Debs, Debs required / suggested / reecommended dependency scheme is better than Red Hat's, but their basic function is the same and frointends like apt and urpmi run on either).
In fact, the LSB has been quite lenient with Debian, allowing the Debian folk to say that `alien' provides all the RPM support they need to be LSB compliant.
I don't think you're very aware of the LSB, its content, or its history.
/opt is reserved for the installation of add-on application software packages. (snip) Distributions may install software in/opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
This strongly discourages distribution use of/opt, as they must ask for specific permission of the local sysadmin to install files there.
Since almost all software could be part of a distribution, and Unix has traditionally sorted its files by their type before their application,/opt use by packages is logically quite rare (and in my own opinion rightly so).
The system ran just fine, but soon it got to a point where some packages I was installing with RPM would not install because the RPM database thought things were not installed which actually were (but weren't installed from RPM, so I can understand why it didn't know this). So I ended up having to do forced installs.
That's not the solution to the problem. Any management system ceases to become effective as soon it ceases to be ubiquitous. If your Apache is locally built, and you made the mistake of not packaging it, then you've nullified the effectiveness of the package manager for anything which touches apache.
You say the system administrator should know how to package applications? Why the system administrator? I'd have thought you'd have expected the programmer to do that.
Good point - ideally the programmer should, but its a simple enough case for SysAdmins to learn if they do encounter an unpackaged app.
Have you tried making RPMs? I'm not a programmer by any means but its amazingly simple. Check www.freshrpms.net for a few good tutorials.
Also, some "dependencies" are option, and don't need to exist unless a feature is to be used that needs it. For example, if I'm not using LDAP for web site user logins, why would I need to make sure LDAP is installed if some module that would otherwise use it is smart enough to work right when I'm not using LDAP.
Another good point. This should be handled by a system similar to debs excellent required / suggested / recommended dependency system, which could fairly easily be ported to RPM from what I understand of it.
Finding out a dependency exists when something breaks is no way to manage a system. Knowing what software has been installed on a machine is vital tomaintaining the security of your machines, and having proper uninstalls stops your hard disk from filling with crap. And there's a stack of other benefits.
I find most people who dislike RPM haven't used the system. its very much similar to building an app. Inside the RPM itself is the original tarball of the app (plus maybe a couple of patches) and the spec file which is comprised of:
Metadata, like the name of the app, version, package version, app description, group, copyright
Instructions on how to patch, configure, compile, install, and uninstall software (with extra nifty stuff, like triggers for when other software is installed, able to be added at your own descretion).
Its pretty muc hthe same as if you'd compiled the app without a package manager. RPM just standardizes your build process. You can easily rebuild source RPM for your local architectecture, and RPM will take compiler flags for your own custom configuration options. I like compiling a lot of apps from source too: I just take a few extra moments do it in a standardized fashion. This pays off repeatedly when I'm administering the machine infuture (or if I need to repeat thsi work on another machine).
Yes it is - it is the standard way of installing applications on Linux according to the LSB, which almost every Linux distribution you've heard of, with the notable exception of Slackware, aims to conform to.
but as long as open source is around, there will always be software that is compiled rather than installed through a package manager.
Source sode should be installed through a package manager. If you're a systems administerator and don't know how to package applications, you need to learn because you need it to do your job.
If you have the brains to compile from source, you have the brains to make a source package. I'm tired of inheriting somebodies backyard apache installed, with a bunch of forced packages and non packaged apps. I can't repeat that install on other systems (especially annoying when testing) the install optiosn used aren't documented, and as the author didn't include an `uninstall' target in his Makefile, I can't uninstall it properly (unless I use something like stow, but in that case I may as well package the goddamned app).
Because there's missed dependencies, I find out when something neeeds somethign else when it breaks, rather than before I install it. How it breaks is different with each app. Same with finding out if that app is installed, and how various files on the system got there. In other words, non packaged systems are an absolute mess and I have little time for them.
Learn to package. It's simple, and you and the machines you will manage will be happier for it.
Anyone running Red Hat 7.2 or many other RPM based distributions can easily install apt (or a similar tool, like urpmi, tho I prefer apt) to do the same thing.
The advantage there is that RPM is a standard - currently the older RPM (version 3) is included in the Linux Standards Base, but once Maximum RPM is updated for RPM 4, its extremely likely that RPM 4 will become the standard.
If you're using Red Hat I highly recommend installing it.
This will get round to people making the applications. I'm absolutely fed up with people, especially vendors of proprietary software, making nonstandard software. In my book, standard (LSB) Linux apps are the *only* Linux apps, this means:
They are packaged as RPM 3 files, to allow standard installation, deinstallation, auditing, and management of relationships with other necessary software. Not some interactive self extracting tarball I can only use once unless I do the vendors job and package it myself (which unfortunately is necessary for modern sysadmins if they want to do their job properly).
They use SysV init scripts which live in/etc/init.d. Again, I often have to do the vendors job for them and write the initscript myself. This sucks, I paid my money for a Linux app and I want a Linux app. This means you Sophos Mailmonitor.
General FHS compliance. I should be able to mount / readonly and/var read write and your app should work, once I have configured it. This is too often not the case. This means you StarOffice.
Man pages should always exist (no, not `Debian tells me I need a man page so this is it, I have no actual useful content, write me!' man pages but actual real no-bullshit man pages. Man pages go in/usr/share/man.
Documentation in/usr/share/doc. Not in/usr/lib. Yes, the FHS says you can install non-user executed binaries in/usr/lib, but documentation is not libraries or binaries, never was, and never will be. This means you Citrix.
Die symlinks, die. Linking correct locations to their incorrect locations should be as short term as possible. Yes, this means you Red Hat. Reverse the/etc/init.d ->/etc/rc.d/init.d symlinks now.
UNLESS YOU ASK MY EXPLICIT PERMISSION TO INSTALL EACH FILE SUSE OR ANY OTHER DISTRO HAS NO RIGHT TO DO THINGS TO MY/OPT. Aaaarrgggh Suse!
There will be things you don't like about the LSB and FHS. Personally, I reckon initscripts aren't config files and should live in/sbin. But I put them in/etc/init.d because the FHS says I should. Likewise, if you have a problem with RPM, make it better (apt-get's already a basis for all my Red Hat installs and updates thanks to Freshrpms).
Here in Victoria, Australia we have regular `computer swapmeets' on Sunday at various town halls. Most of the hardware and software sold is legit, including most of the DVDs, but some are obviously pirated through Asia - the case and disc art looks a little different, they typically have chinese / bahasa indonesia subtitles, and they might occasionally be missing a couple of extra features. Sometimes its done quite well, sometimes, they haven't be able to get good cover art for the movie so they've made their own, with often hilarious results. They also occasionally try and reencode films to fit on lower capacity disks, which is pretty nasty.
But if the movie industry won't help me by allowing alll the real DVDs I've brought to be played on my home and work computer (which happen to run Linux), I won't help them by doing their detective work for them.
There is an apt-get get repository for Gnomehide, which includes all the latest GNOME packages for Red Hat 7.2 and is produced by Havoc Pennington from Red Hat.
In your sources.list: rpm http://apt.nixia.no redhat/7.2/i386 gnomehide
This will delete any important system components installed / updated by Ximian, and is likely to break your system. Please moderate it down if possible.
The simplest way to use 7.2.92 is to upgrade, then reinstall Ximian GNOME like it says.
If you did want to get rid of Ximian GNOME, do it with apt-get, avaliable from freshrpms.net. This will make sure your system is always in a working state during the deinstallation process
And lets not forget the dhcpd, which simply doesn't seem to fire up correctly when started for one network interface in machine where there is many. Luckily dhcpd from rh62 works like charm.
I have a multihomed DHCP server with DHCP on a specific interface using RH 7.2. It works fine.
The problem you might be experiencing is the lack of a particular directory (I forget its name). But you can see the name of the directory if you do /etc/init.d/dhcpd start rather than service dhcpd start create the directory and things will be fine. Tailing the log file will also preovide answers if your DHCP server is not starting uo for other reasons.
Also FYI, the Albacore has been made into a museum, and is the BEST submarine tour I've ever been on, better than any WWII boats, and better than the Nautilus.
The downside is they only allow source distribution, because it sorta auto-configures in a massive way during the build.
Then MPlayer violates criterion 2 of the Open Source Definition and is therefore not Open Source. I'd rather buy the similarly non Open Source Crossover and help fund the developers of the LGPL/X11 licensed Wine (many of whom work for Codeweavers, including Alexandre Julliard, the founder o the project). MPlayer also obviously can't handle Sorenson Quicktime.
I own Crossover 1.1, and reading the documentation that comes with the product, in browser WMP is only supported under Netscape 4.7x, because the Windows WMP plugin relies on Javascript quirks not available in Netscape 6, or Galeon, or Konq, or Opera, or (euw) Moz. My own experiements seem to confirm this.
I think part of the trouble here is that IBM is selling these drives as OEM parts, and not retail drives. OEMs generally don't sell systems to the enthusiast market (The group most likely to leave systems running all day). In your average Dell/Compaq/Cow computer, it's preset to go on standby after an hour or so, powering off the drive. Since all of us "power users" don't like those performance-detracting ACPI/APM functions, we always disable them.
What about corporate environments, where PCs aren't typically turned off, and APM/ACPI is generally disabled for stability reasons?
What is that supposed to mean? Am I out of the loop or does linux support swap files (as opposed to partitions) now?
Both - you are out of the loop, and Linux has supported swap files (as opposed to partitions) for quite some time.
I imagine letting Windows suers have to decide on placement for yet another Linux partition confuses them, hence the authors desire for a single partition.
Its not that Symantec don't have a license - that doesn't change that the XP license still seems to forbid PCA. Nobody's come up with a response to that one yet.
Slashdot Mirror
RH has always used /etc/rc.d/init.d.
Yes, but its not standard (according to the LSB). That's why the links from the correct location to the incorrect one now exist. I agree that links are good, but symlinks don't solve every problem, and RH have indicated they will hopefully move to the correct location in future.
If I'm writing software for Linux, I should create it in line with the Linux standard base, which specifies RPM (currently RPM 3) packaging. All LSB distro's should allow me to install that package.
.Debs more useful features to RPM might assist this. But currently, I know I wouldn't like to rely on the LSB (and hence RPM) to install anything rmeotely important on a Debian box.
Yes, Debian includes RPM (so does Slackware) but it doesn't track dependencies on those systems, which makes it pretty worthless.
Agreed. The RPM situation on Debian needs to be improved. Adding some of
This is useful because it allows preple installin that package to
Install in a uniform, non interactive way. This way you can install your package as part of a automated update or rollout to your machines. At my workplace, `apt-get install cybersource-workstation' pulls down every RPM package needed to do work on a cyber workstation, plus config files for printers and similar items, and installs a couple of hundred pieces software automatically across each machine. Doing this without packaging is difficult.
Intelligently deal with configuration files during upgrades
Install, uninstall, and more importantly be queried using the same mechanism, so other admins know what you've done (this can be saved with a lot of documentation, but you'd spend more time documenting the machine than adminning it).
Uninstall the package cleanly (make uninstall is unforunately rare)
But when someone comes up with an "autospec" "autorpm" program which figures out everything to make the RPM file so it becomes as trivial to make it as to install it, I might be more interested.
Its nice that you're open minded. RPM pretty much already comes with something like that already, which automatically adds the libraries an application relies on to its dependencies when creating the package. Besides that, most apps generally only have a couple of dependencies anyway, and they're quite simple ("my printing config needs lpr installed, what package own lpr, add that package to the dependencies list" - its pretty easy).
Maybe that explains why software is so easy to install, uninstall, and update on Debian... its because none of it really exists.
Asides from the lack of logic in yoru sarcasm there (where did I indictae that there aren't any apps for Debian), there's very little difference in ease of use installing software on either Deb or RPM based distro's. Many Debian folk seem unaware that tools like up2date, urmpi and apt exist and come with most RPM based linux distributions. Personally, I apt-get update my Red Hat 7.2 machine from Freshrpms each day.
Lets face it, the LSB is not an objective standard but a crappy attempt at a standard that has succeeded in nothing more than giving Redhat a supposed stamp of approval as not only the defacto Linux standard, but the dejure (sic) Linux standard.
The standard itself seems to speak otherwise.
I don't think you're very aware of the LSB, its content, or its history.
The full quote goes something like this...
/opt is reserved for the installation of add-on application software packages. /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
/opt, as they must ask for specific permission of the local sysadmin to install files there.
/opt use by packages is logically quite rare (and in my own opinion rightly so).
(snip)
Distributions may install software in
This strongly discourages distribution use of
Since almost all software could be part of a distribution, and Unix has traditionally sorted its files by their type before their application,
That's not the solution to the problem. Any management system ceases to become effective as soon it ceases to be ubiquitous. If your Apache is locally built, and you made the mistake of not packaging it, then you've nullified the effectiveness of the package manager for anything which touches apache.
You say the system administrator should know how to package applications? Why the system administrator? I'd have thought you'd have expected the programmer to do that.
Good point - ideally the programmer should, but its a simple enough case for SysAdmins to learn if they do encounter an unpackaged app.
Have you tried making RPMs? I'm not a programmer by any means but its amazingly simple. Check www.freshrpms.net for a few good tutorials.
Also, some "dependencies" are option, and don't need to exist unless a feature is to be used that needs it. For example, if I'm not using LDAP for web site user logins, why would I need to make sure LDAP is installed if some module that would otherwise use it is smart enough to work right when I'm not using LDAP.
Another good point. This should be handled by a system similar to debs excellent required / suggested / recommended dependency system, which could fairly easily be ported to RPM from what I understand of it.
Finding out a dependency exists when something breaks is no way to manage a system. Knowing what software has been installed on a machine is vital tomaintaining the security of your machines, and having proper uninstalls stops your hard disk from filling with crap. And there's a stack of other benefits.
I find most people who dislike RPM haven't used the system. its very much similar to building an app. Inside the RPM itself is the original tarball of the app (plus maybe a couple of patches) and the spec file which is comprised of:
Its pretty muc hthe same as if you'd compiled the app without a package manager. RPM just standardizes your build process. You can easily rebuild source RPM for your local architectecture, and RPM will take compiler flags for your own custom configuration options. I like compiling a lot of apps from source too: I just take a few extra moments do it in a standardized fashion. This pays off repeatedly when I'm administering the machine infuture (or if I need to repeat thsi work on another machine).
RPM isn't the norm on even all Linux systems
Yes it is - it is the standard way of installing applications on Linux according to the LSB, which almost every Linux distribution you've heard of, with the notable exception of Slackware, aims to conform to.
You can run `up2date -u' to download the newer version of RPM and all necessary security / bugfixes for Red Hat 7.2, plus their dependencies.
I meant 6.2 (and yes, up2date works in 6.2).
but as long as open source is around, there will always be software that is compiled rather than installed through a package manager.
Source sode should be installed through a package manager. If you're a systems administerator and don't know how to package applications, you need to learn because you need it to do your job.
If you have the brains to compile from source, you have the brains to make a source package. I'm tired of inheriting somebodies backyard apache installed, with a bunch of forced packages and non packaged apps. I can't repeat that install on other systems (especially annoying when testing) the install optiosn used aren't documented, and as the author didn't include an `uninstall' target in his Makefile, I can't uninstall it properly (unless I use something like stow, but in that case I may as well package the goddamned app).
Because there's missed dependencies, I find out when something neeeds somethign else when it breaks, rather than before I install it. How it breaks is different with each app. Same with finding out if that app is installed, and how various files on the system got there. In other words, non packaged systems are an absolute mess and I have little time for them.
Learn to package. It's simple, and you and the machines you will manage will be happier for it.
I had Red Hat 6.2 loaded with an obsolete RPM version that prevented me to install several packages.
You can run `up2date -u' to download the newer version of RPM and all necessary security / bugfixes for Red Hat 7.2, plus their dependencies.
Anyone running Red Hat 7.2 or many other RPM based distributions can easily install apt (or a similar tool, like urpmi, tho I prefer apt) to do the same thing.
5 5-fr7.i386.rpm
The advantage there is that RPM is a standard - currently the older RPM (version 3) is included in the Linux Standards Base, but once Maximum RPM is updated for RPM 4, its extremely likely that RPM 4 will become the standard.
If you're using Red Hat I highly recommend installing it.
rpm -Uvh http://enigma.freshrpms.net/pub/apt/apt-0.3.19cnc
apt-get check
apt-get update
apt-get install
Documentation in
There will be things you don't like about the LSB and FHS. Personally, I reckon initscripts aren't config files and should live in
Here in Victoria, Australia we have regular `computer swapmeets' on Sunday at various town halls. Most of the hardware and software sold is legit, including most of the DVDs, but some are obviously pirated through Asia - the case and disc art looks a little different, they typically have chinese / bahasa indonesia subtitles, and they might occasionally be missing a couple of extra features. Sometimes its done quite well, sometimes, they haven't be able to get good cover art for the movie so they've made their own, with often hilarious results. They also occasionally try and reencode films to fit on lower capacity disks, which is pretty nasty.
But if the movie industry won't help me by allowing alll the real DVDs I've brought to be played on my home and work computer (which happen to run Linux), I won't help them by doing their detective work for them.
There is an apt-get get repository for Gnomehide, which includes all the latest GNOME packages for Red Hat 7.2 and is produced by Havoc Pennington from Red Hat.
In your sources.list:
rpm http://apt.nixia.no redhat/7.2/i386 gnomehide
This will delete any important system components installed / updated by Ximian, and is likely to break your system. Please moderate it down if possible.
The simplest way to use 7.2.92 is to upgrade, then reinstall Ximian GNOME like it says.
If you did want to get rid of Ximian GNOME, do it with apt-get, avaliable from freshrpms.net. This will make sure your system is always in a working state during the deinstallation process
And lets not forget the dhcpd, which simply doesn't seem to fire up correctly when started for one network interface in machine where there is many. Luckily dhcpd from rh62 works like charm.
/etc/init.d/dhcpd start
I have a multihomed DHCP server with DHCP on a specific interface using RH 7.2. It works fine.
The problem you might be experiencing is the lack of a particular directory (I forget its name). But you can see the name of the directory if you do
rather than
service dhcpd start
create the directory and things will be fine. Tailing the log file will also preovide answers if your DHCP server is not starting uo for other reasons.
Also FYI, the Albacore has been made into a museum, and is the BEST submarine tour I've ever been on, better than any WWII boats, and better than the Nautilus.
Better than Nautilus? Like that would be hard...
Sure, Mplayer is nice, and $free. I was objecting against you (and many others ) calling MPlayer Open Source, which it is not.
The player is open source, the codecs are not.
The downside is they only allow source distribution, because it sorta auto-configures in a massive way during the build.
Then MPlayer violates criterion 2 of the Open Source Definition and is therefore not Open Source. I'd rather buy the similarly non Open Source Crossover and help fund the developers of the LGPL/X11 licensed Wine (many of whom work for Codeweavers, including Alexandre Julliard, the founder o the project). MPlayer also obviously can't handle Sorenson Quicktime.
I own Crossover 1.1, and reading the documentation that comes with the product, in browser WMP is only supported under Netscape 4.7x, because the Windows WMP plugin relies on Javascript quirks not available in Netscape 6, or Galeon, or Konq, or Opera, or (euw) Moz. My own experiements seem to confirm this.
Has this situation changed?
I think part of the trouble here is that IBM is selling these drives as OEM parts, and not retail drives. OEMs generally don't sell systems to the enthusiast market (The group most likely to leave systems running all day). In your average Dell/Compaq/Cow computer, it's preset to go on standby after an hour or so, powering off the drive. Since all of us "power users" don't like those performance-detracting ACPI/APM functions, we always disable them.
What about corporate environments, where PCs aren't typically turned off, and APM/ACPI is generally disabled for stability reasons?
The only times I find myself booting into Windows is to play video games or watch media files that I can't find Linux players for (.wmv).
if you're using Red Hat 7.2, install apt from Freshrpms.net. Then:
apt-get install xine
apt-get source mplayer (you'll have to rebuild the package as Mplayer isn't open source)
Either will play WMP7 and 8 files file.
What is that supposed to mean?
Am I out of the loop or does linux support swap files (as opposed to partitions) now?
Both - you are out of the loop, and Linux has supported swap files (as opposed to partitions) for quite some time.
I imagine letting Windows suers have to decide on placement for yet another Linux partition confuses them, hence the authors desire for a single partition.
Its not that Symantec don't have a license - that doesn't change that the XP license still seems to forbid PCA. Nobody's come up with a response to that one yet.