The tools you will need are relatively unsophisticated; a 30 metre surveyors tape - this is preferable to string (...), a 1-2 metre board or plank with a rope attached to each end to form a loop - this is known as a stalk-stomper... dowsing rods - these should be made of copper, and purchased from an expensive new age shop.
The real problems in RPM
on
Is RPM Doomed?
·
· Score: 5, Insightful
I worked in the initial effort to port apt to RPM, and I can say that 80% of a smooth upgrade process is not in the package manager you use, but in the way you package your software. To allow smooth upgrades, you must package software with upgrades in mind, otherwise it simply won't work. Dpkg's design offers some advantages over RPM, but even so it's possible to have smooth upgrades with RPM.
The author summarizes his article in the following points:
An RPM-based distribution is risky to upgrade.
That is usually true, but it's not the usage of RPM that makes it so, but the lack of a strict packaging policy. Applying the Denian policy to a RPM-based distro can make it much easier to upgrade. On the other hand, using.deb without following Debian's policy would make a mess out of it.
A more complex binary RPM package is often hard, if not impossible to install.
This affirmation makes no sense at all. If it was correctly packaged for your distribution, it will be as easy to install as any other package. If it was designed for a different distribution, it can also happen with dpkg packages. Please note that the package manager offers a mechanism to deploy binaries, all the rest is policy.
The incompatibilities between different versions of the RPM Package Manager added anotherl ayer of complexity.
True. RPM is a mess in the point that it is not an implementation of a design, it is being continually modified in both design and implementation. RPM needs to be stabilized, continuing development should go to a different product.
The developers are forced to consider differences between distributions and create multiple binary packages.
Not RPM's fault. It would happen with.deb packages if multiple major distributions used it with conflicting policies.
From my experience in the past few years, here are the real issues with RPM:
Binary packages are not compatible between distributions, unless they're statically linked and conforming to some kind of packaging standard. Dependency to libraries doesn't mean much: that particular library can be compiled with different options in different distributions. It's not RPM's. Assume that distributions are 100% compatible only because they share a package format is a mistake. Third-party, distribution-agnostic packages should obey a policy shared by all distributions, and that's one of the major points behind UnitedLinux.
Allowing multiple version of the same package to be installed isn't a good idea at all. Packages are different in nature, some will allow multiple versions, others won't (e.g. binaries vs. runtime libraries). Doing so only makes the upgrade process harder. Debian simplified it using a good packaging policy.
Note also that, even in runtime libraries, you should replace versions that have binary compatibility. If you don't explicitly set a soname in the package name, this information is not available at the upgrade time.
Very confuse, non-intuitive pre- and post- install execution order.
Transaction processing and dependency resolution is too slow, due to file dependencies. As stated above, file dependencies should not be abused, and that can only be enforced by a policy.
Too many unnecessary or confuse packaging features, such as triggers. If you have a good packaging policy, you will never need triggers. Read the librpm sources and you'll find hard-coded dependencies for a number of packages. That's stupid, and a symptom that you've done something very, very wrong and didn't notice it until it was too late because you didn't have a packaging policy.
Moving target. Please stop adding features to RPM and modifying existing behaviour, otherwise we'll be always fighting against the package manager while trying to make smooth upgrades happen.
Immediate configuration of packages after installation in a multiple-package transaction. Dpkg's deferred configuration is a better strategy.
Most of the other RPM problems everyone says when touting Dpkg's superiority are myths and can be emulated with RPM (even using Debian's alternatives or debconf with RPM -- diverts is something more complicated to emulate). Dpkg is indeed a superior package manager today, but what people usually see is result of Debian's policy and not a package manager feature per se.
Now, if it could project a virtual screen from the other side, you would have a virtual monitor too. But you would need a table _and_ a wall, but that would be the ultimate portable computer:)
Marcelo is certainly well aware of the existance of many patches that never get included in the main kernel tree, as he maintains Conectiva's kernel package which contains a large amount of vendor patches. He certainly has his reasons for not including the patches to the official kernel -- it certainly would make his life much easier if he reduced the number of vendor patches in Conectiva's tree applying some of these to the main tree. Marcelo is being very conservative regarding the 2.4 tree, and I believe that's the way it should be, considering it's a "stable" kernel.
Nien Numb... I know this guy. He's the one that, after blowing up the second Death Star, declared that "1000 herds of elephants were standing on his feet."
That happened because Lucas based the alien languages in real (obscure) languages, and Mr. Numb's is based in some African dialect that translates to this bizarre elephant statement.
Redhat apparently has some sort of tool (up2date or something) which performs a similar task.
You can use apt-get with Red Hat and other RPM-based distributions. From the apt4rpm page at sourceforge:
"At these pages an attempt is made to introduce the Advanched Package Tool (APT), originally developed for the Debian Linux distribution, to users of rpm based Linux systems. The intention is to explain how to integrate/implement apt on an rpm based system. For the details about the usage of apt itself one is referred to the apt documentation, manual, howto, etc.
APT has been ported from Debian to the rpm based distribution of Conectiva. After the port completed succesfully, Conectiva now uses APT as package management in their distribution. So why is apt4rpm still needed, you may ask? It's not needed anymore for the Conectiva distribution, but for all the other rpm based distributions. Apt needs a defined package repository to work from, and if the distribution you're using does not set up the APT repository on their CD's, or download servers you must create the repository yourself."
... I watched the Lucy Liu episode, which has some heavy RIAA-aligned propaganda against P2P file sharing. It was somewhat disturbing to see that in such a cool show.
On the other, this could easily and very vocally show RedHat, true or not, to be a good OS if you want to avoid security vulnerabilities. FUD victims could be saying to themselves, "These other guys sit on their hands for over a week?? I'm going to go with redhat!"
Probably not a good move now that Red Hat will most likely be excluded from this private CERT list.
Having KDE binaries in/usr/bin completely destroys the possibility of simultaneouly having KDE 2.x and KDE 3 on the same system (say, a server with dozens of users where you want to slowly migrate from one environment to another). Having them on/usr/kde2 and/usr/kde3, or even/opt, sounds much more saner to me. (Shared resources may stay at a common place, but it's up to the upstream maintainers to allow these "shared resources" work as expected.)
One workaround to remain LSB-compliant and still having them separated would be throwing them on/usr/lib/kde2 and/usr/lib/kde3 -- but it's an ugly hack. But so is arbitrarily breaking the standard and placing them in the correct place. Ugh.
From a diary entry I posted in advogato a few days ago:
7 Nov 2001 (updated 7 Nov 2001)
Bash bashing
Let me state that I have nothing against bash itself. I know it's a very fine, full featured shell with many interesting improvements over other shells. Most, if not all, Linux distributions use it as the system's/bin/sh, which is also fine, but it's the fact that it leaks bash-isms when invoked as sh that is somewhat disturbing. First of all, it allows the creation of a multitude of/bin/sh scripts that are not compatible with the Bourne shell -- replace/bin/sh by ash in your system to see the extension of the damage. Now take your bash-contaminated/bin/sh scripts and try to run them in other, erm, Linux-like systems such as commercial SysV or even BSDs. You can try/bin/ksh, but it won't work in all cases, and you'll be forced to use bash. That's, IMHO, very Microsoftian in nature. It's embrace and extend.
What I advocate here is that bash scripts must use #!/bin/bash, not #!/bin/sh. Let Bourne shell scripts use #!/bin/sh, Korn shell scripts use #!/bin/ksh, C shell scripts use #!/bin/csh and so on. Let's stick on standards. It just makes sense!
Posted by Hemos on Fri August 31, 17:01
from the speak-thy-mind dept.
thk writes "Sistina, the main developer of the Global File System, has changed its language from C to SPL (Shakespeare Programming Language). SPL is basically a language to make the source code for programs written with it, resemble a Shakespeare play. Interestingly, the change came just after beta testing, leaving some users a bit miffed. The GFS is an important component of some GPL clustering projects, such as Compaq's SSIC project. The Sistina press release is here."
Ok, here's the straight link for apt packages for Red Hat and a success report:
I just updated ~10 workstations and ~25 production servers from RHL 6.0
and 6.1 to RHL 6.2. It went fine, no troubles [kernels were already
upgraded earlier]. Workstations had ~600 packages (1 GB) worth of RPM's,
the servers ~300 (400 MB).:-)
You can't do that with third-party.deb packages as well, unless the packager follows the distributor's packaging policies. So, if these packages are built in a sensible way and posted in a apt-enabled repository, there's no reason to believe it wouldn't work.
For example, building packages depending on obsolete packages, or packages conflicting with the distro's official packages, is a good way to break apt-get in both Debian and Conectiva.
Re:Aduva: free for non-commercial use only (per FA
on
RPM Package Manager
·
· Score: 2
For connectiva package management - you'll need THEIR RPM'S! - I wish you all the best luck to go
out and find your favourite RPM in their format.
Not quite, apt-get is works fine with Red Hat as well, and possibly Mandrake. Check the apt-rpm mailing list archives for success reports.
The GPU is the unit responsible for the graphical output of the PSX. It handles display and drawing of all graphics. It has the control over an 1MB frame buffer, which at 16 bits per pixel gives you a maximum "surface" of 1024x512 resolution. It also contains a 2Kb texture cache for increased speed. The display can be set for 15-bit color or 24-bit color.
Number crunching:
Because the PSX also totally lacks an FPU. A second coprocessor has been added called the Geometry Transformation Engine or GTE. The GTE is the heart of all 3d calculations on the PSX. The GTE can perform vector and matrix operations, perspective transformation, color equations and the like. It is much faster than the CPU on these operations. It is mounted as the second coprocessor (Cop2) and as such takes up no physical address space in the PSX. The GTE is covered later in the document.
Movies:
The Motion Decoder (MDEC) is a special controller chip that takes a compressed JPEG-like images and decompresses them into 24-bit bitmapped images for display by the GPU. The MDEC can only decompress a 16x16 pixel 24-bit image at at time,called "Macroblocks" These Macrobock are encoded block that uses the YUV (YCbCr) color scheme with Discrete Cosine Transformation (DCT) and Run Length Encoding (RLE) applied The MDEC also performs 24 to 16 bit color conversion to prepare it for whatever color depth the GPU is in. Due to the extremely high speed that the decompression is done, the decompressed RGB bitmaps can be combined to from larger pictures and then,if displayed in sequential order, to produce movies.
Sound:
The SPU has 24 hardware voices. These voices can be used to reproduce sample data, noise or can be used as frequency modulator on the next voice. Each voice has it's own programmable ADSR envelope filter. The main volume can be programmed independently for left and right output.
Slashdot Mirror
Well... as long as they're circles, and are made in crops, they're real crop circles...
Anyway, here's an interesting HOWTO you can follow to create your own circles. Here's an excerpt: ;)
The author summarizes his article in the following points:
- An RPM-based distribution is risky to upgrade.
.deb without following Debian's policy would make a mess out of it.
- A more complex binary RPM package is often hard, if not impossible to install.
- The incompatibilities between different versions of the RPM Package Manager added anotherl ayer of complexity.
- The developers are forced to consider differences between distributions and create multiple binary packages.
.deb packages if multiple major distributions used it with conflicting policies.
From my experience in the past few years, here are the real issues with RPM:That is usually true, but it's not the usage of RPM that makes it so, but the lack of a strict packaging policy. Applying the Denian policy to a RPM-based distro can make it much easier to upgrade. On the other hand, using
This affirmation makes no sense at all. If it was correctly packaged for your distribution, it will be as easy to install as any other package. If it was designed for a different distribution, it can also happen with dpkg packages. Please note that the package manager offers a mechanism to deploy binaries, all the rest is policy.
True. RPM is a mess in the point that it is not an implementation of a design, it is being continually modified in both design and implementation. RPM needs to be stabilized, continuing development should go to a different product.
Not RPM's fault. It would happen with
- Binary packages are not compatible between distributions, unless they're statically linked and conforming to some kind of packaging standard. Dependency to libraries doesn't mean much: that particular library can be compiled with different options in different distributions. It's not RPM's. Assume that distributions are 100% compatible only because they share a package format is a mistake. Third-party, distribution-agnostic packages should obey a policy shared by all distributions, and that's one of the major points behind UnitedLinux.
- Allowing multiple version of the same package to be installed isn't a good idea at all. Packages are different in nature, some will allow multiple versions, others won't (e.g. binaries vs. runtime libraries). Doing so only makes the upgrade process harder. Debian simplified it using a good packaging policy.
Note also that, even in runtime libraries, you should replace versions that have binary compatibility. If you don't explicitly set a soname in the package name, this information is not available at the upgrade time.
- Very confuse, non-intuitive pre- and post- install execution order.
- Transaction processing and dependency resolution is too slow, due to file dependencies. As stated above, file dependencies should not be abused, and that can only be enforced by a policy.
- Too many unnecessary or confuse packaging features, such as triggers. If you have a good packaging policy, you will never need triggers. Read the librpm sources and you'll find hard-coded dependencies for a number of packages. That's stupid, and a symptom that you've done something very, very wrong and didn't notice it until it was too late because you didn't have a packaging policy.
- Moving target. Please stop adding features to RPM and modifying existing behaviour, otherwise we'll be always fighting against the package manager while trying to make smooth upgrades happen.
- Immediate configuration of packages after installation in a multiple-package transaction. Dpkg's deferred configuration is a better strategy.
Most of the other RPM problems everyone says when touting Dpkg's superiority are myths and can be emulated with RPM (even using Debian's alternatives or debconf with RPM -- diverts is something more complicated to emulate). Dpkg is indeed a superior package manager today, but what people usually see is result of Debian's policy and not a package manager feature per se.Now, if it could project a virtual screen from the other side, you would have a virtual monitor too. But you would need a table _and_ a wall, but that would be the ultimate portable computer :)
You mean, by adding a steam turbine and a generator inside each laptop?
Marcelo is certainly well aware of the existance of many patches that never get included in the main kernel tree, as he maintains Conectiva's kernel package which contains a large amount of vendor patches. He certainly has his reasons for not including the patches to the official kernel -- it certainly would make his life much easier if he reduced the number of vendor patches in Conectiva's tree applying some of these to the main tree. Marcelo is being very conservative regarding the 2.4 tree, and I believe that's the way it should be, considering it's a "stable" kernel.
That happened because Lucas based the alien languages in real (obscure) languages, and Mr. Numb's is based in some African dialect that translates to this bizarre elephant statement.
You can use apt-get with Red Hat and other RPM-based distributions. From the apt4rpm page at sourceforge:
"At these pages an attempt is made to introduce the Advanched Package Tool (APT), originally developed for the Debian Linux distribution, to users of rpm based Linux systems. The intention is to explain how to integrate/implement apt on an rpm based system. For the details about the usage of apt itself one is referred to the apt documentation, manual, howto, etc.
APT has been ported from Debian to the rpm based distribution of Conectiva. After the port completed succesfully, Conectiva now uses APT as package management in their distribution. So why is apt4rpm still needed, you may ask? It's not needed anymore for the Conectiva distribution, but for all the other rpm based distributions. Apt needs a defined package repository to work from, and if the distribution you're using does not set up the APT repository on their CD's, or download servers you must create the repository yourself."
... I watched the Lucy Liu episode, which has some heavy RIAA-aligned propaganda against P2P file sharing. It was somewhat disturbing to see that in such a cool show.
Probably not a good move now that Red Hat will most likely be excluded from this private CERT list.
Just use a different name server then.
One workaround to remain LSB-compliant and still having them separated would be throwing them on /usr/lib/kde2 and /usr/lib/kde3 -- but it's an ugly hack. But so is arbitrarily breaking the standard and placing them in the correct place. Ugh.
7 Nov 2001 (updated 7 Nov 2001)
(Hey wait, yt has been done too...)
Yeah, but remember that anchovies are not extinct... yet!
thk writes "Sistina, the main developer of the Global File System, has changed its language from C to SPL (Shakespeare Programming Language). SPL is basically a language to make the source code for programs written with it, resemble a Shakespeare play. Interestingly, the change came just after beta testing, leaving some users a bit miffed. The GFS is an important component of some GPL clustering projects, such as Compaq's SSIC project. The Sistina press release is here."
Speak thy mind!
So, who's going to port Stella to PS2?
In that case, GNU should expand to "GNU's not GNU/Unix". Hrm... something is wrong here.
OTOH with the original Unix tools and the Linux kernel, you'll put an end in the "Linux vs. GNU/Linux" war.
For example, building packages depending on obsolete packages, or packages conflicting with the distro's official packages, is a good way to break apt-get in both Debian and Conectiva.
Most of the content in Conectiva's site is in http://distro.conectiva.com.br, including news, projects, updates, security annoucements and a webcam.
Check the current development status in freshmeat, at the bottom of the page.
Graphics:
- The GPU is the unit responsible for the graphical output of the PSX. It handles display and drawing of all graphics. It has the control over an 1MB frame buffer, which at 16 bits per pixel gives you a maximum "surface" of 1024x512 resolution. It also contains a 2Kb texture cache for increased speed. The display can be set for 15-bit color or 24-bit color.
Number crunching:- Because the PSX also totally lacks an FPU. A second coprocessor has been added called the Geometry Transformation Engine or GTE. The GTE is the heart of all 3d calculations on the PSX. The GTE can perform vector and matrix operations, perspective transformation, color equations and the like. It is much faster than the CPU on these operations. It is mounted as the second coprocessor (Cop2) and as such takes up no physical address space in the PSX. The GTE is covered later in the document.
Movies:- The Motion Decoder (MDEC) is a special controller chip that takes a compressed JPEG-like images and decompresses them into 24-bit bitmapped images for display by the GPU. The MDEC can only decompress a 16x16 pixel 24-bit image at at time,called "Macroblocks" These Macrobock are encoded block that uses the YUV (YCbCr) color scheme with Discrete Cosine Transformation (DCT) and Run Length Encoding (RLE) applied The MDEC also performs 24 to 16 bit color conversion to prepare it for whatever color depth the GPU is in. Due to the extremely high speed that the decompression is done, the decompressed RGB bitmaps can be combined to from larger pictures and then
,if displayed in sequential order, to produce movies.
Sound: