The Debian way to "mass deploy" packages is probably using the apt-get system. You simply add your own package repository to your "sources list", and use apt-get to install/upgrade the packages. They do provide gpg signing, if you want security.
And exactly this is usually accomplished under (say) Mandriva using urpmi/rpmdrake, by adding your repository with urpmi.addmedia. However, this is not the mass-deploy aspect referred to, which on Mandriva is provided by urpmi-parallel (to install/upgrade/remove the same set of packages on a group of machines). Similar functionality exists for Red Hat from RHN, but I'm not aware of any other distribution having a system like this.
But this still implies it is a problem with the hardware, whereas it is apparently the update software for Windows. Since my new Compaq 6910p (Core 2 Duo) laptop hasn't got a functional version of Windows, my laptop is currently immune. While the exploit may affect most HP/Compaq laptops, an accurate subject is what/.ers would prefer.
1. 64-bits was relegated to very-low-priority (an inordinate number of supposedly-supported 64-bit packages had dependency failures)
I note that a lot of users insisting on running a 64bit OS for no other reason than they have an x86_64 CPU (which is quite a lame reason - specifically if you have less than 2GB ram in said machine) don't notice that Mandriva has always had good dual-arch support. This means that you can transparently install and run the 32bit packages as well (which for a long time was impossible on Debian and all derivatives, where the only way to run 32bit apps was via 32bit chroot). Unfortunately, this, and the fact that some packages (OpenOffice.org, and all it's dependencies) were installed from 32bit packages by default (for good reason), meant that you would have both architecture packages. Invariably, users would add just the 64bit update repos (and not the 332bit ones as well), and then wonder why they have conflicts between different releases of different architectures of the same package....
Some of these issues have been improved, but I note that all distros with multi-arch support have problems educating users (such as "use rpm -q --qf %{ARCH}\n" to see what architecture the package is, "remember to install the 32bit nss_ldap if you have 32bit apps - specifically proprietary ones - running as users authenticated via LDAP, etc. etc.).
I have within the past couple of months received acknowledgements for bugs that I filed nearly two years ago -- and those acknowledgements basically came down to "this bug report is filed against a version that is no longer supported".
This is actually evidence of the fact that bug reports are now being handled more pro-actively than in the past...
4. Official update mirrors would disappear for weeks at a time
Distributions have little control over what mirror providers do, but there are some improvements that could be made to the mirroring situation.
5. Security updates would be made available weeks after exploits became known.
Sorry, but this is pure FUD. I make a point of looking at the delays in issuing updates for vulnerabilities on lwn.net, and Mandriva is usually ahead of at least two other main-stream distros (e.g. Fedora, Ubuntu, Gentoo).
I ended up running cooker to try to keep up to date and try packages that were not available as stable.
This problem has been solved since the release of 2007.0, which introduced new media on the mirrors, and at the same time changes to the build system allowing maintainers to easily submit testing and backport packages from cooker.
At present, selection of packages to backport is mainly done by the maintainer, but requests are often taken on IRC and mailing lists.
IMHO, there is almost no advantage Ubuntu has over Mandriva (besides hype).
Ah, but this is a different issue. This is some proprietary Unix password input functions only reading 8 characters, whereas the AOL one is more likely the crypt()-type problem of discarding all but the first 8 letters when hashing the password. Your case there isn't much you can do (as the input is discarded), but in the 2nd case, authenticating against anything but the local passwd/shadow file would fix it (e.g. pam_krb5 or pam_ldap would respect all the characters).
Another reason not to use proprietary Unix (AIX, HP-UX) where SAOX is an issue (and avoid authenticating locally on Solaris up to at least Solaris 9, maybe even 10).
For example, I have 4 drives encrypted (dm-crypt).. Does unga bunga have all the device mapper and crypt support built into its kernel?
Also, I auth against an LDAP machine, so I need nss-ldap and pam-ldap and all of that jibber jabber. Samba needs to be able to join my samba-controlled domain, too.
Any current linux distro will ship all of these. E.g., on Mandriva 2006 or later, dm-crypt is present, and drakauth (does Ubuntu have a UI for authentication configuration yet, or will I have to *keep* helping Ubuntu users on #ldap ?) will happily set LDAP auth up for you. And any version of samba after 2.2 should be able to join another samba domain.
The only reason I switched from it was that I was dumb enough to do a full upgrade of Mandriva 2006 to 2007 shortly after 2007 was released.
It's not dumb to do an upgrade... it is supported. However, you do need to read the errata, especially the section on installation for the new release to know about the potential problems.
Remember that a lot of users (those who run cooker) do upgrades (via urpmi) daily or weekly...
"RPM Hell is a common way of referring to it". RPM doesn't allow concurrent version of libraries in a simple way and we can go on with arguments like this ones for a long time.
This is not a problem with rpm, it is only the way it is used. Mandriva has allowed multiple library versions installed in parallel since about 8.1 (due to the library packaging policy).
Also if Redhat and Mandriva and Suse are using it, that doesn't mean it's a good system. Most Fedora people use APT and so do many Mandriva and Opensuse users.
Those users of apt are still using rpm. apt for rpm is less maintained than rpm is, so you're arguing against yourself here.
RPM distributions are bad for Linux because commercial software producers are doing packages in this format and that's not for a technical reason but only for commercial agreements.
You haven't provided one statement that compares the technical differences between rpm and dpkg. Compare apt to urpmi or yum or smart, compare rpm to dpkg, and the rpm format to the deb format.
The only standard for third-party software under Linux (LSB) specifies RPM. So, RPM distributions have no effect, get the LSB to change rather than trolling about rpm -based distributions.
You seem to be the typical clueless debian apt vs rpm (which is an invalid argument) troll...
One of the contributors to Mandriva developed a drop-in parallel init system, which uses LSB tags in the init scripts to determine dependencies. This was tested in the development version for a while, until it was selected as the default before the release of Mandriva 2007.0.
Back when I still had to work on Windows boxes, I found a version of sudo for Windows 2000. It took a little bit of work assigning the rights required to be able to use it, but it worked fine. Of course, there's not much fun running rundll32 with the right arguments... but there were some uses.
Note of course that sudo isn't only used on Ubuntu... it's only Ubuntu that has a brain-dead permit-all default rule. sudo rules should really be tailored to semi-dangerous commands that will not wreak havoc (or otherwise it is quite trivial to write a script that first gets the user to enter their password for some less dangerous command, and then run some more dangerous commands).
It would probably be possible to make a system that uses process-based concurrency and works well on Win32. Win32 has plenty of inter-process communication mechanisms that are very efficient, and the scheduler handles this situation with no problems.
But, performance would still suck, as fork() (or it's equivalent) is a lot more expensive on Windows than on Unix, and this is one of the bigger drivers for moving from a multi-process model to a multi-threaded model on Windows.
Most enterprises have security policies that don't allow compilers on production servers. This immediately makes Gentoo a lot more effort to use on production servers than distros that require binary packages to work (where binary packages on Gentoo are an after-thought, and using only binary packages loses all the advantages of the distro).
We run minimal installs (you're lucky if you get vim instead of vi) of RPM-based distributions, and have a build host which supports all the releases we run in production, with internal repos. And we know that all our production servers are using the same packages, and that we can rebuild any server in under 20 minutes.
I must not be that savvy today, after 10 minutes of searching, I still don't have an answer as to why I am unable to connect to a 2003 exchange server.
It works under Linux. The fact that it does not work under Windows may be due to this being an alpha build.
There are *some* Exchange/Outlook features which aren't available under Evolution (I haven't managed to accept a task request, or the document "Voting" buttons that apparently appear under Outlook don't have any effect in Evolution), but it *can* replace Outlook for most daily work.
And, if users on Windows really need to use an MS client... the OWA interface is essentially outlook under Windows (but is painful on Linux/Firefox).
I work in a big corporate, run Linux on my desktop (since it is just more productive than Windows for everything besides scheduling meetings) and use Evolution on Linux to access the corporate Exchange servers.
I haven't tried posting to a public folder, but reading anything in a public folder is no problem.
I used Evolution to give my team leader, project manager and a colleague access to my tasks.
Evolution actually *requires* OWA to work, not sure if it uses HTTPS, but I assume it should.
So, I assume the Windows version will probably have all the same features when it is final.
Assuming you mean rpm vs dpkg, this is irrelevant. rpm has very few problems to fix.
I am sick of downloading packages from weird websites
If you're running RedHat, you shouldn't really be doing this anyway, you should be using up2date.
If you need packages not supplied by RedHat, there are repos for RedHat.
But, this has nothing to do with "fixing the package manager", it is more about the available packages on RedHat. However, a lot of the packages *I* need that are missing on RedHat (we have approx 150 source packages in our internal repo which we build for RHEL2, 3 and 4) aren't packaged in Ubuntu. And, some of the ones I need which *are* available on RedHat, aren't available on Ubuntu either.
YUM seems tacked on, and I've never gotten it to work properly.
While yum isn't IMHO the best rpm tool equivalent of apt, I've never seen it not work.
Now, you've been comparing apt to rpm, but there are many other aspects to package management that RedHat does get right, for example the features of up2date/RHN:
-grouping of servers and scheduling of updates (that you can show your CTO, not some script) -profiles in RHN for kickstarting servers -config file channels (something like cfengine, but built into RHN) -ability to kickstart servers from the RHN interface
With an RHN satellite server, you can have custom channels, which you can then use for both of the above, but doing all package management from the satellite server.
So, don't compare rpm to apt (which is a mistake in itself) because RedHat ships/supports fewer packages, and then leave out all the features RedHat *does* have regarding package management.
Also, last I checked Ubuntu's kickstart was still missing lots of features I actually use (even though we don't use Satellite, we use kickstart and our own repos, which we use to install packages during the %post section of kickstart using smart.
The only reason to use package managers is if you are new to Linux or just don't want to learn much.
Why didn't you just take the time to learn RPM?
Hint: portage is a package management system, just as rpm is, but you probably didn't bother with rpm-build.
Binary packages have advantages as well:
fast deployment (we can deploy the entire software stack and configs and updates for a new server in under 15 minutes)
certification
easier tracking of the origin of the software
verification of all the components of the package
integrity checking on all the files in the package
Now, you can build RPMs from source, which gives you the majority of the advantages any source-based system gives you, and if you handle it well, you can also get revision control of both source and binary packages. There are good package managers available for all binary-based distros, which remove any semblance of "dependany hell". I find many people simultaneously complain that "my previous distro prevented me from learning" and "my previous distro had dependancy hell". If you had bothered to spend as much time learning about the package management tools on the previous distro as you spent instlaling Gentoo, you would not have had depenancy hell.
So, I don't really see that (eg.) Gentoo has many advantages, and it just wouldn't be allowed in many environments (in ours, compilers are not permitted on production machines).
Maintainer of ~ 90 (source) packages in a binary-based distribution (not counting packages only for internal use)
When you have a small to medium business all with computers on an active directory domain
But, then this doesn't qualify as Office, but as Exchange... they are not inter-dependant, and using Office without Exchange won't get you these features.
I mean, I use thunderbird
Which has a standards-based calendar plugin. Granted, this doesn't quite provide the same features yet (except maybe with Kolab via synckolab).
and I think office is way overpriced. But, for what it is, outlook 2003 is a pretty good business product. It's relatively secure (compared to past iterations), the shared calendar is easy to use (yes there are open source alternatives
Actually, the open-source alternatives would be Kolab+Kontact on the Linux side, or Thunderbird+synckolab or Outlook with a (proprietary) connector), or horde (which has full calendaring support for Horde). IMHO, web-only based tools don't count. In a while, Evolution and Kontact will likely be available on Windows too...
but integration and ease of use are hard to match here), and with Small Business Server, the outlook web interface has a lot of Ajax and DHTML type features which make it look almost exactly like you're at your computer.
Except if you use a different browser. If you look closer, it's not just DHTML and Ajax, but one large dll which gets downloaded to the client machine on first use, and relies on insecure and proprietary technologies (ie ActiveX).
It's very well executed.
I wouldn't agree, it is quite poor under Firefox (ie no better than a run-of-the-mill webmail client from the 90s), which is why I avoid it (and use Evolution to access our Exchange server - I use kmail for our non-Exchange server).
I would say Oracle has an LDAP server, that's not very standards compliant, and that they may try and convince people can replace OpenLDAP. Whether OID really can is another matter. Performance-wise, apparently it can't.
BTW, OpenLDAP isn't the only LDAP server that uses Berkeley DB on the backend, FDS/RHDS (the copy of Netscape Directory Server RedHat bought) and JES (Sun's copy of Netscape Directory server they got via the iPlanet alliance) do too.
But what's it like to replace only the BerkeleyDB with Oracle, under an OpenLDAP server?
Just like replacing any fast local database backend (bdb) with another abstraction (SQL) to a model (tables) that doesn't represent the frontend (hierarchical) that well, really bad for performance. OpenLDAP can already use any ODBC/SQL backend, though it's really not the first choice (the only real use is to expose data already in such a database via LDAP, not as a high performance LDAP server). Oracle, DB2, Postgresql, and MySQL have been used successfully (ie it works, but performance is always bad, no matter which is used).
And what's it like to then drop the OpenLDAP part, leaving only OID?
Mandriva also uses the patch, and provides the tools to generate the delta rpms (in the "deltarpm" package), so here are some extracts from the man page:
NAME
makedeltarpm - create a deltarpm from two rpms
DESCRIPTION
makedeltarpm creates a deltarpm from two rpms. The deltarpm can later
be used to recreate the new rpm from either filesystem data or the old
rpm. Use the -v option to make makedeltarpm more verbose about its work
(use it twice to make it even more verbose).
If you want to create a smaller and faster to combine "rpm-only"
deltarpm which does not work with filesystem data, specify the -r
option. [...]
urpmi is supposed to support the deltas, and they were being tested on cooker at some stage, but it doesn't seem that deltas are being used for the current update media.
-printerdrake (if Mandriva installation didn't find your printer - ie network printer or similar), which you can run from the Mandriva Control Center -system-config-printer (RedHat/Fedora) -(I guess SUSE has something similar in yast2)
Sorry, but having to know the 4 packages you need to install, then manually choose the backend (or figure out the foomatic command-line necessary) doesn't qualify as "easy".
Slashdot Mirror
And exactly this is usually accomplished under (say) Mandriva using urpmi/rpmdrake, by adding your repository with urpmi.addmedia. However, this is not the mass-deploy aspect referred to, which on Mandriva is provided by urpmi-parallel (to install/upgrade/remove the same set of packages on a group of machines). Similar functionality exists for Red Hat from RHN, but I'm not aware of any other distribution having a system like this.
But this still implies it is a problem with the hardware, whereas it is apparently the update software for Windows. Since my new Compaq 6910p (Core 2 Duo) laptop hasn't got a functional version of Windows, my laptop is currently immune. While the exploit may affect most HP/Compaq laptops, an accurate subject is what /.ers would prefer.
http://www.catalystframework.org
I note that a lot of users insisting on running a 64bit OS for no other reason than they have an x86_64 CPU (which is quite a lame reason - specifically if you have less than 2GB ram in said machine) don't notice that Mandriva has always had good dual-arch support. This means that you can transparently install and run the 32bit packages as well (which for a long time was impossible on Debian and all derivatives, where the only way to run 32bit apps was via 32bit chroot). Unfortunately, this, and the fact that some packages (OpenOffice.org, and all it's dependencies) were installed from 32bit packages by default (for good reason), meant that you would have both architecture packages. Invariably, users would add just the 64bit update repos (and not the 332bit ones as well), and then wonder why they have conflicts between different releases of different architectures of the same package
Some of these issues have been improved, but I note that all distros with multi-arch support have problems educating users (such as "use rpm -q --qf %{ARCH}\n" to see what architecture the package is, "remember to install the 32bit nss_ldap if you have 32bit apps - specifically proprietary ones - running as users authenticated via LDAP, etc. etc.).
This is actually evidence of the fact that bug reports are now being handled more pro-actively than in the past
Distributions have little control over what mirror providers do, but there are some improvements that could be made to the mirroring situation.
Sorry, but this is pure FUD. I make a point of looking at the delays in issuing updates for vulnerabilities on lwn.net, and Mandriva is usually ahead of at least two other main-stream distros (e.g. Fedora, Ubuntu, Gentoo).
This problem has been solved since the release of 2007.0, which introduced new media on the mirrors, and at the same time changes to the build system allowing maintainers to easily submit testing and backport packages from cooker.
At present, selection of packages to backport is mainly done by the maintainer, but requests are often taken on IRC and mailing lists.
IMHO, there is almost no advantage Ubuntu has over Mandriva (besides hype).
Ah, but this is a different issue. This is some proprietary Unix password input functions only reading 8 characters, whereas the AOL one is more likely the crypt()-type problem of discarding all but the first 8 letters when hashing the password. Your case there isn't much you can do (as the input is discarded), but in the 2nd case, authenticating against anything but the local passwd/shadow file would fix it (e.g. pam_krb5 or pam_ldap would respect all the characters).
Another reason not to use proprietary Unix (AIX, HP-UX) where SAOX is an issue (and avoid authenticating locally on Solaris up to at least Solaris 9, maybe even 10).
Any current linux distro will ship all of these. E.g., on Mandriva 2006 or later, dm-crypt is present, and drakauth (does Ubuntu have a UI for authentication configuration yet, or will I have to *keep* helping Ubuntu users on #ldap ?) will happily set LDAP auth up for you. And any version of samba after 2.2 should be able to join another samba domain.
It's not dumb to do an upgrade
Remember that a lot of users (those who run cooker) do upgrades (via urpmi) daily or weekly
This is not a problem with rpm, it is only the way it is used. Mandriva has allowed multiple library versions installed in parallel since about 8.1 (due to the library packaging policy).
Those users of apt are still using rpm. apt for rpm is less maintained than rpm is, so you're arguing against yourself here.
You haven't provided one statement that compares the technical differences between rpm and dpkg. Compare apt to urpmi or yum or smart, compare rpm to dpkg, and the rpm format to the deb format.
The only standard for third-party software under Linux (LSB) specifies RPM. So, RPM distributions have no effect, get the LSB to change rather than trolling about rpm -based distributions.
You seem to be the typical clueless debian apt vs rpm (which is an invalid argument) troll
This has been possible for ages (I definitely used it on 8.1 and 8.2). You may need a separate /boot for this though.
One of the contributors to Mandriva developed a drop-in parallel init system, which uses LSB tags in the init scripts to determine dependencies. This was tested in the development version for a while, until it was selected as the default before the release of Mandriva 2007.0.
See more information on prcsys
The advantages with prcsys are:
-traditional serial startup can be used
-minimal changes are required to initscripts
-LSB compliance for free
The Fedora wiki has some good discussion of why some aspects of new fangled init systems may not be desirable.
Back when I still had to work on Windows boxes, I found a version of sudo for Windows 2000. It took a little bit of work assigning the rights required to be able to use it, but it worked fine. Of course, there's not much fun running rundll32 with the right arguments ... but there were some uses.
... it's only Ubuntu that has a brain-dead permit-all default rule. sudo rules should really be tailored to semi-dangerous commands that will not wreak havoc (or otherwise it is quite trivial to write a script that first gets the user to enter their password for some less dangerous command, and then run some more dangerous commands).
Note of course that sudo isn't only used on Ubuntu
It would probably be possible to make a system that uses process-based concurrency and works well on Win32. Win32 has plenty of inter-process communication mechanisms that are very efficient, and the scheduler handles this situation with no problems.
But, performance would still suck, as fork() (or it's equivalent) is a lot more expensive on Windows than on Unix, and this is one of the bigger drivers for moving from a multi-process model to a multi-threaded model on Windows.
Most enterprises have security policies that don't allow compilers on production servers. This immediately makes Gentoo a lot more effort to use on production servers than distros that require binary packages to work (where binary packages on Gentoo are an after-thought, and using only binary packages loses all the advantages of the distro).
We run minimal installs (you're lucky if you get vim instead of vi) of RPM-based distributions, and have a build host which supports all the releases we run in production, with internal repos. And we know that all our production servers are using the same packages, and that we can rebuild any server in under 20 minutes.
I must not be that savvy today, after 10 minutes of searching, I still don't have an answer as to why I am unable to connect to a 2003 exchange server.
... the OWA interface is essentially outlook under Windows (but is painful on Linux/Firefox).
It works under Linux. The fact that it does not work under Windows may be due to this being an alpha build.
There are *some* Exchange/Outlook features which aren't available under Evolution (I haven't managed to accept a task request, or the document "Voting" buttons that apparently appear under Outlook don't have any effect in Evolution), but it *can* replace Outlook for most daily work.
And, if users on Windows really need to use an MS client
I work in a big corporate, run Linux on my desktop (since it is just more productive than Windows for everything besides scheduling meetings) and use Evolution on Linux to access the corporate Exchange servers.
I haven't tried posting to a public folder, but reading anything in a public folder is no problem.
I used Evolution to give my team leader, project manager and a colleague access to my tasks.
Evolution actually *requires* OWA to work, not sure if it uses HTTPS, but I assume it should.
So, I assume the Windows version will probably have all the same features when it is final.
Fix your package manager!
Assuming you mean rpm vs dpkg, this is irrelevant. rpm has very few problems to fix.
I am sick of downloading packages from weird websites
If you're running RedHat, you shouldn't really be doing this anyway, you should be using up2date.
If you need packages not supplied by RedHat, there are repos for RedHat.
But, this has nothing to do with "fixing the package manager", it is more about the available packages on RedHat. However, a lot of the packages *I* need that are missing on RedHat (we have approx 150 source packages in our internal repo which we build for RHEL2, 3 and 4) aren't packaged in Ubuntu. And, some of the ones I need which *are* available on RedHat, aren't available on Ubuntu either.
YUM seems tacked on, and I've never gotten it to work properly.
While yum isn't IMHO the best rpm tool equivalent of apt, I've never seen it not work.
Now, you've been comparing apt to rpm, but there are many other aspects to package management that RedHat does get right, for example the features of up2date/RHN:
-grouping of servers and scheduling of updates (that you can show your CTO, not some script)
-profiles in RHN for kickstarting servers
-config file channels (something like cfengine, but built into RHN)
-ability to kickstart servers from the RHN interface
With an RHN satellite server, you can have custom channels, which you can then use for both of the above, but doing all package management from the satellite server.
So, don't compare rpm to apt (which is a mistake in itself) because RedHat ships/supports fewer packages, and then leave out all the features RedHat *does* have regarding package management.
Also, last I checked Ubuntu's kickstart was still missing lots of features I actually use (even though we don't use Satellite, we use kickstart and our own repos, which we use to install packages during the %post section of kickstart using smart.
So, I can see why RH isn't worried about Ubuntu.
The only reason to use package managers is if you are new to Linux or just don't want to learn much.
Why didn't you just take the time to learn RPM?
Hint: portage is a package management system, just as rpm is, but you probably didn't bother with rpm-build.
Binary packages have advantages as well:
Now, you can build RPMs from source, which gives you the majority of the advantages any source-based system gives you, and if you handle it well, you can also get revision control of both source and binary packages. There are good package managers available for all binary-based distros, which remove any semblance of "dependany hell". I find many people simultaneously complain that "my previous distro prevented me from learning" and "my previous distro had dependancy hell". If you had bothered to spend as much time learning about the package management tools on the previous distro as you spent instlaling Gentoo, you would not have had depenancy hell.
So, I don't really see that (eg.) Gentoo has many advantages, and it just wouldn't be allowed in many environments (in ours, compilers are not permitted on production machines).
Maintainer of ~ 90 (source) packages in a binary-based distribution (not counting packages only for internal use)
But, then this doesn't qualify as Office, but as Exchange
I mean, I use thunderbird
Which has a standards-based calendar plugin. Granted, this doesn't quite provide the same features yet (except maybe with Kolab via synckolab).
and I think office is way overpriced. But, for what it is, outlook 2003 is a pretty good business product. It's relatively secure (compared to past iterations), the shared calendar is easy to use (yes there are open source alternatives
Actually, the open-source alternatives would be Kolab+Kontact on the Linux side, or Thunderbird+synckolab or Outlook with a (proprietary) connector), or horde (which has full calendaring support for Horde). IMHO, web-only based tools don't count. In a while, Evolution and Kontact will likely be available on Windows too
but integration and ease of use are hard to match here), and with Small Business Server, the outlook web interface has a lot of Ajax and DHTML type features which make it look almost exactly like you're at your computer.
Except if you use a different browser. If you look closer, it's not just DHTML and Ajax, but one large dll which gets downloaded to the client machine on first use, and relies on insecure and proprietary technologies (ie ActiveX).
It's very well executed.
I wouldn't agree, it is quite poor under Firefox (ie no better than a run-of-the-mill webmail client from the 90s), which is why I avoid it (and use Evolution to access our Exchange server - I use kmail for our non-Exchange server).
Oracle can replace OpenLDAP, as OID
I would say Oracle has an LDAP server, that's not very standards compliant, and that they may try and convince people can replace OpenLDAP. Whether OID really can is another matter. Performance-wise, apparently it can't.
BTW, OpenLDAP isn't the only LDAP server that uses Berkeley DB on the backend, FDS/RHDS (the copy of Netscape Directory Server RedHat bought) and JES (Sun's copy of Netscape Directory server they got via the iPlanet alliance) do too.
But what's it like to replace only the BerkeleyDB with Oracle, under an OpenLDAP server?
Just like replacing any fast local database backend (bdb) with another abstraction (SQL) to a model (tables) that doesn't represent the frontend (hierarchical) that well, really bad for performance. OpenLDAP can already use any ODBC/SQL backend, though it's really not the first choice (the only real use is to expose data already in such a database via LDAP, not as a high performance LDAP server). Oracle, DB2, Postgresql, and MySQL have been used successfully (ie it works, but performance is always bad, no matter which is used).
And what's it like to then drop the OpenLDAP part, leaving only OID?
Slow and expensive?
Mandriva also uses the patch, and provides the tools to generate the delta rpms (in the "deltarpm" package), so here are some extracts from the man page:
NAME
makedeltarpm - create a deltarpm from two rpms
SYNOPSIS
makedeltarpm [-v] [-V version] [-z compression] [-s seqfile] [-r] [-u]
oldrpm newrpm deltarpm
makedeltarpm [-v] [-V version] [-z compression] [-s seqfile] [-u] -p
oldrpmprint oldpatchrpm oldrpm newrpm deltarpm
DESCRIPTION
makedeltarpm creates a deltarpm from two rpms. The deltarpm can later
be used to recreate the new rpm from either filesystem data or the old
rpm. Use the -v option to make makedeltarpm more verbose about its work
(use it twice to make it even more verbose).
If you want to create a smaller and faster to combine "rpm-only"
deltarpm which does not work with filesystem data, specify the -r
option.
[...]
urpmi is supposed to support the deltas, and they were being tested on cooker at some stage, but it doesn't seem that deltas are being used for the current update media.
Compared to:
-printerdrake (if Mandriva installation didn't find your printer - ie network printer or similar), which you can run from the Mandriva Control Center
-system-config-printer (RedHat/Fedora)
-(I guess SUSE has something similar in yast2)
Sorry, but having to know the 4 packages you need to install, then manually choose the backend (or figure out the foomatic command-line necessary) doesn't qualify as "easy".
For me it's all about will I be able to build my tarballs
Build tarballs?
In an enterprise environment?
You must be kidding.
Red Hat has lots of tools that make deployment quick and easy, *especially* for the admins who know their stuff.
And don't forget about the ability to run commercial applications such as MS Office and Photoshop
...
I guess you mean the availability of those applications.
There are plenty of commercial applications for Linux. Even proprietary ones. With GUIs. Expensive ones too