Hello,
this is my first post on the redhat-dev mailing list, but I'd like to share some ideas with you people, that might increase the ease of use for redhat.
please be aware that this is my opinion, and I'm sure that your opinion or comments will be appreciated!
(and don't shoot me for some stuff, because I haven't read the complete docs on the site yet ;-)
here we go:
RedHat has made an excellent decision when using the RedHat-network stuff... the update checker, so no comments there.
But on the other side, people that aren't used to Linux (in general) will have problems installing/adding software. The rpm system is nice, but If you can't find an rpm that's compiled for your exact system, you're in trouble. And let's not forget the infamous dependancy hell!
So why not use apt-like system (I'll call it apt from now on)? I know that there are probably a lot of arguments as why not to use it, but consider the advantages:
It might be possible to have an installation version that is only 1 cd. This can then only contain the basic system, window manager, and some basic applications (if a system like knoppix can do this...). It is then possible to use apt to get people to install applications, without having to download 3 cd's in a row. (even with a graphical frontend like Synaptic)
Also good about this, is that it can reduce debate about which packages need to be included with the distribution itself, and which not. And people will have 'official' redhat packages, for those that don't trust third-party stuff.
What do you guys think?
bye,
David.
Am Mit, 2003-07-23 um 09.24 schrieb david paeme:
So why not use apt-like system (I'll call it apt from now on)? I know that there are probably a lot of arguments as why not to use it, but consider the advantages:
or yum, which looks more stable to me.
It might be possible to have an installation version that is only 1 cd. This can then only contain the basic system, window manager, and some basic applications (if a system like knoppix can do this...). It is then possible to use apt to get people to install applications, without having to download 3 cd's in a row. (even with a graphical frontend like Synaptic)
Nice idea, it is like Debian, Gentoo or *BSD but i see a problem: There are still a lot of modem and ISDN (in Germany) users out on the net. For those people it is impossible to use apt/yum etc. to install big things like KDE or GNOME. They still need CDs/DVDs to simple install packages without waiting for weeks until all packages are downloaded. I think there must be a distro which has more than one CD.
regards André
On Wed, 2003-07-23 at 09:52, André Kelpe wrote:
Am Mit, 2003-07-23 um 09.24 schrieb david paeme:
So why not use apt-like system (I'll call it apt from now on)? I know that there are probably a lot of arguments as why not to use it, but consider the advantages:
or yum, which looks more stable to me.
well, I was just using apt because everybody knows that one ;-) (i presume)
It might be possible to have an installation version that is only 1 cd. This can then only contain the basic system, window manager, and some basic applications (if a system like knoppix can do this...). It is then possible to use apt to get people to install applications, without having to download 3 cd's in a row. (even with a graphical frontend like Synaptic)
Nice idea, it is like Debian, Gentoo or *BSD but i see a problem: There are still a lot of modem and ISDN (in Germany) users out on the net. For those people it is impossible to use apt/yum etc. to install big things like KDE or GNOME. They still need CDs/DVDs to simple install packages without waiting for weeks until all packages are downloaded. I think there must be a distro which has more than one CD.
regards André
you're right about that, but why not go for a stable/testing/addon system, a bit like debian uses?
I mean, you can take general packages, and create a distribution out of it (RedHat 10?), which contains everything that a working system needs, but still quite restricted: instead of a few different mail clients, let's just put evolution on the cd. if someone wants another one, let them install sylpheed without a hassle (apt or yum or ripm -- redhat internet package manager?? -- just kidding). or xmms as standard (with mp3, please...), and alsaplayer and stuff as extra's via apt?
maybe even the basic system on one cd, with the repository snapshot on the other cd's? and let a utility like synaptic the take care of installing software from cd or some ftp?
who knows...
maybe the idea needs some more discussion, but I really think that an apt-like system is what redhat needs. it's the only thing that's really missing from the distro...
At 00:24 2003/07/23, david paeme wrote:
RedHat has made an excellent decision when using the RedHat-network stuff... the update checker, so no comments there.
But on the other side, people that aren't used to Linux (in general) will have problems installing/adding software. The rpm system is nice, but If you can't find an rpm that's compiled for your exact system, you're in trouble. And let's not forget the infamous dependancy hell!
So why not use apt-like system (I'll call it apt from now on)?
This is an improvement that I'd like to see, yes, essentially a "smarter" package manager with an awareness of prerequisites, where to find them, and how to install them. A next-generation RPM, effectively :)
On the other hand, I have a long-standing problem with RPMs and the updating system. While it's quite useful for workstation installations (where almost all packages are pre-compiled with suitable default options), it's all but useless on server installations, where custom configurations are common.
As a case in point, if I happen to use IBM DB2 as my database of choice (or necessity) on a given server, I'll end up having to (re)build packages like PHP from sources in order to configure --with-ibm-db2 or somesuch. The RPM-based PHP distributions won't have been compiled with that option (though they may have MySQL support compiled in), so there's no way around building from sources in most cases. This not only defeats the purpose of RPMs for these applications, it also makes it impossible to use the automated updating features of the RH network, since that system relies on a registry of installed binary RPMs. If I built PHP 4.3.2 from sources and the up2date system saw that I had a previously-installed PHP 4.3.2 binary RPM installation, it might well upgrade me to the PHP 4.3.3 binary RPM, overwriting my custom build.
What I'd like to see in RPMs for server packages is something like dynamic compilation based on some checkboxes or command-line flags that describe the options to autoconf. Essentially a higher-level interface to ./configure, which could be used to build a custom installation of the package, and store those settings (e.g. from config.status) so that later the up2date process could use those to properly build future versions without breaking the existing installation. If the configuration options are not backward-compatible, have up2date simply download the updated package and flag it for the administrator to deal with manually.
If none of this is feasible, then at least consider compiling as many available options as possible into the binary distributions you package into RPMs, so that custom recompilations (which break up2date) won't be necessary in as many cases. Sure, this will result in larger, more bloated binaries, but at least they'll have all the optional support features built-in, so that there should be no need to rebuild the packages from sources later, even if you switch from MySQL to DB2, or something similar. Think of the way the installation kernel contains driver support for almost everything, to ensure that almost all hardware will be able to run the installation. If you're going to package binary distributions of applications in an RPM, and you want that to be automatically update-able, you'll have the most success when people are able to use that package "as-is", without having to make custom builds for themselves.
Robert LeBlanc
On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
At 00:24 2003/07/23, david paeme wrote:
So why not use apt-like system (I'll call it apt from now on)?
Well, it looks like 'yum' is in Rawhide now so RH is considering/working such a thing. And the project page seems to indicate some hope on some form of integration w/ r-c-p.
This is an improvement that I'd like to see, yes, essentially a "smarter" package manager with an awareness of prerequisites, where to find them, and how to install them. A next-generation RPM, effectively :)
Seperate APT from DEB in your head and realize the same must be done w/ RPM...
As a case in point, if I happen to use IBM DB2 as my database of choice (or necessity) on a given server, I'll end up having to (re)build packages like PHP from sources in order to configure --with-ibm-db2 or somesuch. The RPM-based PHP distributions won't have been compiled with
And your vendor doesn't provide such packages? I'd think for something as 'enterprise' as DB2 is there are base changes like this that IBM would provide the new based-on-RH RPMs.
What I'd like to see in RPMs for server packages is something like dynamic compilation based on some checkboxes or command-line flags that describe the options to autoconf. Essentially a higher-level interface to ./configure, which could be used to build a custom installation of the
Ick. Ouch. *spit* You don't mean at install time, do you? I mean, what's so bad about taking your SRPM and futzing your changes there?
And you could always help out Fedora.us or Freshrpms.net to post updated RPMs as such (if you're not using RHEL)..
For your case above I quite literally recommend taking it up w/ your vendor and asking them what they certify on. I'm sure there are other cases though..
Cheers, -Ali
At 02:14 2003/07/23, Ali-Reza Anghaie wrote:
On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
As a case in point, if I happen to use IBM DB2 as my database of choice (or necessity) on a given server, I'll end up having to (re)build packages like PHP from sources in order to configure --with-ibm-db2 or somesuch. The RPM-based PHP distributions won't have been compiled with
And your vendor doesn't provide such packages? I'd think for something as 'enterprise' as DB2 is there are base changes like this that IBM would provide the new based-on-RH RPMs.
It's not entirely fair (or effective) to try to pin this issue on the vendors, expecting them to solve every conceivable incompatibility issue. In this example I singled out IBM DB2, but the same problem applies to many other packages, whether they're closed-source or not. If I download a MySQL (or PHP, or Apache, or...) binary distribution, I have no guarantee that it has all the necessary options compiled into it for my specific needs.
The problem at the root of all this is that if I ever need to rebuild anything from sources, I break the auto-update chain for that package. The fact that I've applied a (developer-defined) customization effectively means I can no longer have security updates and bug-fixes applied without doing them by hand. What I'd rather see is a system flexible enough to detect (e.g. by reading the equivalent of a config.status file) the configuration options that were used to build a package in the first place, and then applying these to updated sources--*or*--have it search for a binary distribution that was compiled with those specific options enabled.
The latter may in the end be the more feasible option for RH. Essentially have the RPM information itself keep track of what options were used to compile the package, so that people who need a set of binaries compiled with options X, Y, and J can search on this basis, and make this a requirement for any auto-updates.
Robert LeBlanc
On Wed, Jul 23, 2003 at 12:20:38PM -0700, Robert LeBlanc wrote:
At 02:14 2003/07/23, Ali-Reza Anghaie wrote:
On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
As a case in point, if I happen to use IBM DB2 as my database of choice (or necessity) on a given server, I'll end up having to (re)build packages like PHP from sources in order to configure --with-ibm-db2 or somesuch. The RPM-based PHP distributions won't have been compiled with
And your vendor doesn't provide such packages? I'd think for something as 'enterprise' as DB2 is there are base changes like this that IBM would provide the new based-on-RH RPMs.
It's not entirely fair (or effective) to try to pin this issue on the vendors, expecting them to solve every conceivable incompatibility issue. In this example I singled out IBM DB2, but the same problem applies to many other packages, whether they're closed-source or not. If I download a MySQL (or PHP, or Apache, or...) binary distribution, I have no guarantee that it has all the necessary options compiled into it for my specific needs.
The problem at the root of all this is that if I ever need to rebuild anything from sources, I break the auto-update chain for that package. The fact that I've applied a (developer-defined) customization effectively means I can no longer have security updates and bug-fixes applied without doing them by hand. What I'd rather see is a system flexible enough to detect (e.g. by reading the equivalent of a config.status file) the configuration options that were used to build a package in the first place, and then applying these to updated sources--*or*--have it search for a binary distribution that was compiled with those specific options enabled.
The latter may in the end be the more feasible option for RH. Essentially have the RPM information itself keep track of what options were used to compile the package, so that people who need a set of binaries compiled with options X, Y, and J can search on this basis, and make this a requirement for any auto-updates.
There are two problems here: 1) how the build system is set up. 2) how the package was built.
The build system for RHL is setup by using build dependencies for all but a handful of packages like gcc and make.
How the package was built is encoded in the spec file, and rpm by design guarantees that each and every rpm started from a spec file, virgin sources, etc and ran to completion in some build system.
Yes there is no explicit config.status, basically because there is no need if you are using RHL packages, or custom modifications of RHL packages, or simple additions to RHL distros.
73 de Jeff
At 12:58 2003/07/23, Jeff Johnson wrote:
On Wed, Jul 23, 2003 at 12:20:38PM -0700, Robert LeBlanc wrote:
The problem at the root of all this is that if I ever need to rebuild anything from sources, I break the auto-update chain for that
package. The
fact that I've applied a (developer-defined) customization effectively means I can no longer have security updates and bug-fixes applied without doing them by hand. What I'd rather see is a system flexible enough to detect (e.g. by reading the equivalent of a config.status file) the configuration options that were used to build a package in the first
place,
and then applying these to updated sources--*or*--have it search for a binary distribution that was compiled with those specific options enabled.
The latter may in the end be the more feasible option for RH. Essentially have the RPM information itself keep track of what options were used to compile the package, so that people who need a set of binaries compiled with options X, Y, and J can search on this basis, and make this a requirement for any auto-updates.
There are two problems here: 1) how the build system is set up. 2) how the package was built.
The build system for RHL is setup by using build dependencies for all but a handful of packages like gcc and make.
How the package was built is encoded in the spec file, and rpm by design guarantees that each and every rpm started from a spec file, virgin sources, etc and ran to completion in some build system.
Yes there is no explicit config.status, basically because there is no need if you are using RHL packages, or custom modifications of RHL packages, or simple additions to RHL distros.
Sorry, but I feel a bit like I've been "talked in circles", here :) I've been describing the problems inherent in "custom modifications of RHL packages", namely that any need to rebuild anything from sources (e.g. to recompile a package with a different set of configuration options) breaks the auto-updating capability for that package. I'm confused by the last sentence of your response, though, which seems to imply that there's no problem here at all. Could you clarify that a bit more?
I confess to being an old-timer, having used Linux since kernel 0.99.12 when *everything* had to be assembled by hand. I'm well used to the process of downloading a source tarball, configuring and building the sources, and installing packages that way. When RPM came along I was initially impressed--package installation was about to become a whole lot easier and more streamlined, I thought. This is certainly true for "out of the box" installations, like for mass-deployment on workstations, but for servers I've simply determined that RPM and its auto-updating facilities are just false hopes--I can't (and therefore don't) use them, as too much customization tends to be required for server apps.
The downside of doing everything manually, of course, is that I now have to keep abreast of bug and security fixes myself, and apply them all by hand to my sources, rebuild them, and reinstall them. I'd really like the convenience of the auto-updating facility--and would find it worth paying for--if it could actually work for me. The fact that it can't unless I straightjacket myself with "standard" binary installations is frustrating.
I'd like to see a more flexible, versatile approach in any "next-generation" RPM/up2date system, and that's what I'm trying to petition for here. Either a Gentoo-like system that can build applications at install time with user-specified options selected, or at least a means of making the option set visible somewhere within the RPM package, so that when updates are downloaded for those packages the up2date process can search for RPMs built with those particular options. I'm sure there are other solutions that would work as well, given a little time and thought, and a willingness to make changes on this level.
If, on the other hand, you really feel this is a problem that doesn't exist, or one that would require more work to fix than you're willing to invest, just say so and I'll shut up. I'm only trying to help make the RPM/up2date system live up to its initial promise, and if indeed you believe it's as good as it can get I'll drop the matter and go back to my tarballs, or to Gentoo.
Robert LeBlanc
On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
As a case in point, if I happen to use IBM DB2 as my database of choice (or necessity) on a given server, I'll end up having to (re)build packages like PHP from sources in order to configure --with-ibm-db2 or somesuch.
The problem at the root of all this is that if I ever need to rebuild anything from sources, I break the auto-update chain for that package.
What's the Big Picture/Goal? RHL Project users get no "Support" from RH. Apparently this does not preclude RH from collecting money for RHN subscriptions to distribute and apply updates. Obviously for the example above, RH is going to provide support for DB2 in RHEL. RH's goal isn't to supply the serious do it yourselfer like Robert with everything he needs in RHL Project but instead in RHEL. Robert however, like myself, doesn't want to pay big bucks for support that we will almost never use (maybe his is willing but RH didn't speakup and say, "that's in RHEL"). We need to find a balance in all this. I see RH is being very careful but maybe too careful. If RH actually "is" willing support an array of PHP rpms, etc, for various configurations to cover the needs of people like Robert but "only" in RHEL and Robert is willing to pay for the convienence then that dialog needs to happen. Obviously RH is a large company which needs to make money so this is understandable but RH is being a little tight lipped about what they have going in RHEL and probably haven't decided it all yet.
On the other hand for people like Robert and myself who "aren't" willing to pay big bucks when we can do it ourselves but are willing to contribute to RHL Project, RH needs to work with us or lose us. I personally am considering moving to RHEL when 3.0 is released but I need to check it out first. They have said to me, "Talk to us, we give volume discounts. At low volumes." Not formalizing and publishing the volume discounts is very short sighted because more than half of the prospective RHEL customers my size never talk to them after seeing the price and multiplying it times the number of servers (7 in my case). We just say to our selves, "forget it, it cost too much".
If RHL Project is supported only by the community, then the community will move to one of the free update distribution systems if RH does not work with us. For example RHL Project is GPL. I can install it on 10 computers or 50 computers. RHEL has a satellite RHN server. Because it's technically easy for the community to write a light version of this, we will (and have) if RH does not. We are do it yourselfers. Include in RHL Project a light RHN satellite that only the do it yourselfer can use:
rpm -i rhn-sat.... dhcp.conf: update_server=192.168.0.1 Done! Simple but not automatic. The masses will have one computer and pay for update the way they are now.
With this RH collects $100 / year / channel (or whatever) for a subscription which feeds the rhn-satellite all the updates only once. Then "Do it Yourself IT" can have an infinate number of installs in their company and RH never has to answer a single support call but is making just a little money from *many* small businesses. IMHO RH can not reserve convienient security updates for RHEL. But if they approach it from the right angle they can succeed big time. The other companies which are willing to spend $500K to save $2M will use RHEL for all the other advantages it has.
As for updating custom installs here is what is needed for both RHL Project and RHEL. Someone sugguested something close to this: All updates are released as not only bin and src rpms but also a src-diff rpm which installs patches for the update in an "unapplied patches" dir in the src tree for that package. This rpm is dependent on prior patches and the original src rpm. The only thing the do it yourselfer needs to do to take advantage of this when he needs to modify a package is to force the uninstall of the binary rpm first and then compile and install from the src rpm. Up2date will then do the right thing without mods. If we don't get carried away with diffs from every point to every point then this won't be very much extra work to support, just one patch rpm in addition to the src rpm (correct me if making a dif rpm is labor intensive). If the diff rpm cats an entry in a "src-update" log file then after running up2date -u the do-it-yourselfer only needs to check it for new entries to know which packages need recompiled. He then applies, compiles and then moves the patches to the "applied patches" folder and he's all set. Perhaps rpm can be taught to update a src rpm, simulating the diff rpm above, to accomplish all this without any other changes! A single update to rpm and a howto and it's all done!
I honestly believe RH can be a raving success if they strike a good balance between the do-it-yourselfer and the enterprise.
Sorry for being so wordy but I hope it helps.
Scott Becker
On Fri, 2003-07-25 at 12:20, Scott Becker wrote:
If RH actually "is" willing support an array of PHP rpms, etc, for various configurations to cover the needs of people like Robert but "only" in RHEL and Robert is willing to pay for the convienence then that dialog needs to happen. Obviously RH is a large company which needs to make money so this is understandable but RH is being a little tight lipped about what they have going in RHEL and probably haven't decided it all yet.
If you need the ability to call Red Hat and get support for anything Linux related, you will need to be using RHEL. Do we support the PHP rpms we ship in RHEL? Of course.
Yes, we are being tight-lipped on what we have going in RHEL, and part of this is due to the fact that the next release of RHEL is just barely in Beta. Features may be added/dropped while we're in this stage.
If anyone would like to talk about RHEL, either contact your sales representative (if you have one) or email me directly, and I will be happy to discuss it with you as far as I can. Recognize that an NDA may be necessary to get into the fine details, such is the nature of the game, pre-release.
Not formalizing and publishing the volume discounts is very short sighted because more than half of the prospective RHEL customers my size never talk to them after seeing the price and multiplying it times the number of servers (7 in my case). We just say to our selves, "forget it, it cost too much".
Do you pay list price for your hardware? Do you pay list price for ANY software application? I suspect the answer is no on both counts, but you HAVE to engage the Sales machine in order to get that volume discount. Almost no computer business entities publish their volume sales discounts (outside of the channel). Red Hat is not unique in this regard.
Striking a middle ground between the needs of the "do-it-yourselfer" and the "enterprise" is far trickier than you've detailed. Any approach taken has to be sure not to weaken the position on either side.
If you find yourself needing telephone support or Red Hat guaranteed updates, you're sliding onto the enterprise side. Give Red Hat a call, let us try to work with you to see if RHEL is an option.
~spot --- Tom "spot" Callaway <tcallawa(a)redhat*com> SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260
The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me.
"Immature poets borrow, mature poets steal." --- T. S. Eliot
Tom 'spot' Callaway wrote:
On Fri, 2003-07-25 at 12:20, Scott Becker wrote:
Not formalizing and publishing the volume discounts is very short sighted because more than half of the prospective RHEL customers my size never talk to them after seeing the price and multiplying it times the number of servers (7 in my case). We just say to our selves, "forget it, it cost too much".
Do you pay list price for your hardware? Do you pay list price for ANY software application? I suspect the answer is no on both counts, but you HAVE to engage the Sales machine in order to get that volume discount. Almost no computer business entities publish their volume sales discounts (outside of the channel). Red Hat is not unique in this regard.
We have seven servers accumulated/updated over 5 years. We paid list for all of it. I understand you have to work through your system but I recommend at least mentioning a volume discounts exists. We have 20 windows workstations bought one or two at a time over five years with no discount except that the OS was less by being bundled with the hardware. There is no yearly fee to keep windows updated. Windows sucks of course and updates will end soon for the version I'm using. I've bought a few servers with no OS and I think it was only $30 less. I work for the kind of small business where we don't have any volume in our IT (me). The RH seminar in Seattle which I attended (first ever) is where I found out about about volume discounts.
I just carefully read the page on "Enterprise Linux ES" and found "For Volume Sales: Contact Sales" which implies volume discount but I still, after all this, don't know if 7 servers would give me a discount. I know, "Call Sales and talk to them." but a little more info on the site may intice an average Joe like me to actually call.
Striking a middle ground between the needs of the "do-it-yourselfer" and the "enterprise" is far trickier than you've detailed. Any approach taken has to be sure not to weaken the position on either side.
Understood.
Scott Becker
On Fri, 2003-07-25 at 13:39, Scott Becker wrote:
I just carefully read the page on "Enterprise Linux ES" and found "For Volume Sales: Contact Sales" which implies volume discount but I still, after all this, don't know if 7 servers would give me a discount. I know, "Call Sales and talk to them." but a little more info on the site may intice an average Joe like me to actually call.
Not me. If I need to find out something and can't find it immediately, I call ASAP and find out what I need to know, least business wise.