No-one who has used dselect will ever go back to RPM.
Actually, dselect has been known to drive users the hell away from Debian. Its interface is rotten, and the authors agree. It's unfortunate, since dselect and apt really do good things. It just takes a bit of adjustment to get used to dselect.
I was considering moving over to Debian myself before apt became available for rpm. I'm much less motivated now ; )
Re:Binary Distros Are Dead
on
Is RPM Doomed?
·
· Score: 3, Insightful
Updates and upgrades typically require much less bandwidth than their binary equivelents, as only the new package's source needs to be downloaded.
Source is almost never significantly smaller than binary, and often is bigger. Consider bash: -rw-r--r-- 26 root root 701486 Apr 16 21:14/var/ftp/mnt/valhalla-i386-disc1/RedHat/RPMS / ash-2.05a-13.i386.rpm -rw-r--r-- 24 root root 2144412 Apr 16 21:14/var/ftp//mnt/valhalla-SRPMS-disc1/SRPMS/bas h-2.05a-13.src.rpm
the system is auto-healing, meaning that if and when a new library is installed and the older one removed, all packages that rely on that library are recompiled against the new library.
In the case of rpm or dpkg, the system protects itself from damage caused by replacing a package that others depend on. Attempting to do so will result in a list of all of the packages which additionally need to be updated to work with the new library. If you're using apt (for dpkg or rpm), attempting to update a library will fetch binary upgrades for the packages which need it. Source Mage doesn't have the advantage here.
...the day long install (on my dual 1 GHz P3), which has already shrunk to less than half a day...
Day long? I don't know many with anywhere near the time for that. I can install a Red Hat Linux server on a clean box in all of two minutes from initial power up to fully functional reboot.
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm.... There needs to be a FILES file with a list of installed files with a gen-files script
Actually, you can do that. The old KDE packages did; I don't know if the new ones do. It's very easy to do if your source produces only one binary package. However, if you want to split things into more than one binary pacakge, then it is up to you to determine which files belong in which package. You can still do this automatically, but it's usually easier just to list the files in the rpm spec.
For many of those who use the term GNU/Linux, it's not about credit, but accuracy.
Personally, I try to always say what I mean: GNU when I'm talking about the user tools, usually in contrast to the BSD tools. Linux when I'm referring specifically to a kernel capability. Red Hat Linux when I discuss the distribution I use, and the features thereof. GNU/Linux when I'm talking about GNU/Linux systems in general.
Linux by itself does not fulfill the requirements of a UNIX operating system. GNU/Linux does.
When you understand the term GNU/Linux as the full name of a UNIX platform, rather than an ego-stroking byline, you can see that suggestions like "Apache/Slashdot" aren't valid criticisms.
Removing copyright technology of a work whose copyright has expired, therefore, would not violate the DMCA.
Good point, but how do you suppose that's going to be done? The DMCA outlaws any tools whose primary purpose is to circumvent copyright technology. You're going to find it hard to argue that a tool which can be used to circumvent copyright tech is only going to be used on works which have passed into the public domain, I'll wager.
you cannot force an author to publish a work in a a medium which is easy to copy.
I see where you're coming from, but isn't that the point of copyright? It's a legal grant of the *right* to copy a work which expires, and after which all are supposed to have the right to copy the work. If that right to copy is denied to the public forever, why do the publishers continue to get legal copying monopoly?
Being NAL as I am, I would like to see some discussion of how limited term copyright is expected to work in a future where copyright is enforced by perpetual technological means.
As more information is published on digital media, DRM is becoming a means of enforcing the copyright on the information. However, I know of no DRM systems which provide for expriation of protection. So, while the legal protection may go away after the granted term, the data is still protected technologically. I wonder, what are the legal implications of this?
Copyright was granted on the grounds that after the granted term, the information was to enter the public domain. If the information is designed by the distributors to never enter the public domain, does it still deserve copyright protection? It seems like this is analogous to patents vs. trade secrets where trade secrets have no legal protection because there is no obligation to disclose the way they work. You have to trade one for the other.
While many readers poo-poo the study because it was funded by Clorox, I wonder who else they expect to conduct such studies? Clorox makes cleaning products... it makes sense for them to find out what things need cleaning, no?
I wouldn't expect the average person to go around collecting samples from all of the surfaces in their house to grow in dishes and find problematic places.
The results don't surprise me at all. Anyone who's taken a high-school level biology course has probably done exactly that in class and found that commonly handled items have lots of bacteria. I believe door knobs and phones were the worst surfaces tested by my class. (which reminds me of a particular chapter of the hitchhikers guide...)
2) Microsoft must release full API documentation detailing all APIs that non-OS tasks can call.
I wouldn't stop there. Some of the best products are OS add-ins. New filesystems, security products, even drivers depend on the OS API. Why would you want to leave it out?
I was about to suggest that you include a copy of libstdc++ with your application, but I just noticed that the RPM package and serveral files in the CVS repository all bear the GPL. That would make it illegal to link proprietary applications against libstdc++, wouldn't it?:( I think I'm going to bring this up on the redhat-list and see if anyone has anything to say about this...
because you continue to use a proprietary compiler version?
It's not "proprietary". All of the code is available. It's Free Software.
Wow, I was wondering if the Linux media player still existed anywhere... I figured MS would have later hunted down and eliminated all evidence of its existance.
Comments like this make me wish there weren't a 5 point cap on moderation, or a moderation category like "Not repeated enough" (as opposed to redundant:-)
Sale or disposure of the copy does not, however, free the copy from the original copyright. What part of the GPL do you think prohibits the resale of copies of software? The GPL specifically grants all recipients of copies the same rights as the source from which they got the copies.
Does anyone else have a Linux version of *their* media player? Does Real or M$?
Yes, and yes. Real player for Linux is available, and at one point in time, there was even a Media Player for Linux available from MS. The MS player is, as far as I know, gone now though:)
Red Hat does not pre-announce release dates or version numbers. I find it highly unlikely that 8.0 will follow in anything less than the ~6 month release cycle that they've always followed. IF 8.0 is what follows at all...
We've been told that Hampton was a code name used for an internal development tree, and is not expected to be the name of the final release (whatever the version number)
You should *never* use --nodeps to install packages. The only time that is reasonable is if you've built a particular dependency from source, yourself (which you should avoid).
Certainly, you should never advise new users, in a public forum, that --nodeps is the correct way to go. They *will* end up with non-functioning installations.
...because RPM can't do something like "a.rpm needs library X, let's see if any of the other RPM's in this directory have library X in them."
That's total bull shit. rpm absolutely, positively does resolve dependencies against both the packages already installed in the system and the packages given to install.
New users should not follow these directions. Other replies to the parent post give proper installation instructions. Moderators should lay down the crack pipe, and decrease the score on the parent post.
Those numbers are only misleading if you don't know how to read them. Top and ps have a reputation for misleading people stemming from users' confusion over what the different segments mean.
To clarify (I hope): The SIZE of an application reflects the paging area that has been allocated to the application. This includes all of the text and data for the application, all of the mmap'd files, everything.
The SHAREd pages include all pages of the application's memory marked shared. This is independent of whether or not anything is actually sharing the pages. A program may be linked against Motif, for instance; it will show the size of Motif as shared space, although the memory may still be attributed entirely to that process.
The RSS reflects the RAM resident pages for the application's text and data segments. The difference between RSS and SHARED *at least* may be attributed entirly to the program. It's hard to tell if the difference between RSS and SIZE can, as well, since it could be swapped out shared pages.
As an unusual case, X also mmap's the video memory on your graphics card, which inflates its SIZE value.
I'd still say that KDE is *fucking huge*. Given the numbers from the poster, I wonder how much swap is being used. All of the processes listed have much larger paging areas (SIZE) than resident memory area (RSS), which probably means there's a lot of it out in swap. I wonder if these binaries were compiled with debugging symbols and not stripped, or something...
I hate to see the parent marked up at 5. Personally, I think it is far more misleading than the output of 'top'.
Re:KDE3 -pre is in Red Hat's Skipjack
on
KDE 3.0 is Out
·
· Score: 2
Tooltips are very nearly junk. They're only really useful when used to describe icons that don't have labels; that's only acceptable if the labels would have taken up too much space to make the UI usable.
Displaying the description in the app menu should make it immediately obvious what the menu items *do*, and damn what they *are*. Why should anyone care about the name of the application they're using? Isn't the function of the software what's important?
Re:Gnome Panel and descriptions
on
KDE 3.0 is Out
·
· Score: 3, Interesting
I know about the tooltips, but that doesn't help novices much. Can you imagine a novice user looking at the menu for the first (or second, or...) time and mouse-over'ing every item? (Ooo, what's this? Ooo, what's this? etc.)
KDE's panel can now display the comment *as the menu label* which is what I suggested to the GNOME devel group way-back-when.
KDE3 -pre is in Red Hat's Skipjack
on
KDE 3.0 is Out
·
· Score: 5, Interesting
I tried the CVS release of KDE 3 included in Red Hat's Skipjack beta. Like a man admiring his neighbor's well groomed lawn, I've got to say that it looks *beautiful*. There's some good stuff in there.
One of my favorite features is that the panel can optionally display the "description" of each item, rather than the "name" of the application. That's far more useful for the novice user. I suggested that the GNOME panel do that about.... 2 years ago (??) on one of the gnome mailing lists, but never got around to submitting a patch myself.
Ogg Vorbis has a specification for its file format that doesn't break any previously specified standard. Therefore, Ogg Vorbis can be called a standard.
yEnc, on the other hand, breaks the NNTP standards, and will likely break the MIME standard. That's the difference. yEnc must fit within the standards already specified for the transmition methods it uses, and does not.
Slashdot Mirror
No-one who has used dselect will ever go back to RPM.
Actually, dselect has been known to drive users the hell away from Debian. Its interface is rotten, and the authors agree. It's unfortunate, since dselect and apt really do good things. It just takes a bit of adjustment to get used to dselect.
I was considering moving over to Debian myself before apt became available for rpm. I'm much less motivated now ; )
Updates and upgrades typically require much less bandwidth than their binary equivelents, as only the new package's source needs to be downloaded.
/var/ftp/mnt/valhalla-i386-disc1/RedHat/RPMS / ash-2.05a-13.i386.rpm /var/ftp//mnt/valhalla-SRPMS-disc1/SRPMS/bas h-2.05a-13.src.rpm
...the day long install (on my dual 1 GHz P3), which has already shrunk to less than half a day...
Source is almost never significantly smaller than binary, and often is bigger. Consider bash:
-rw-r--r-- 26 root root 701486 Apr 16 21:14
-rw-r--r-- 24 root root 2144412 Apr 16 21:14
the system is auto-healing, meaning that if and when a new library is installed and the older one removed, all packages that rely on that library are recompiled against the new library.
In the case of rpm or dpkg, the system protects itself from damage caused by replacing a package that others depend on. Attempting to do so will result in a list of all of the packages which additionally need to be updated to work with the new library. If you're using apt (for dpkg or rpm), attempting to update a library will fetch binary upgrades for the packages which need it. Source Mage doesn't have the advantage here.
Day long? I don't know many with anywhere near the time for that. I can install a Red Hat Linux server on a clean box in all of two minutes from initial power up to fully functional reboot.
In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm. ... There needs to be a FILES file with a list of installed files with a gen-files script
Actually, you can do that. The old KDE packages did; I don't know if the new ones do. It's very easy to do if your source produces only one binary package. However, if you want to split things into more than one binary pacakge, then it is up to you to determine which files belong in which package. You can still do this automatically, but it's usually easier just to list the files in the rpm spec.
For many of those who use the term GNU/Linux, it's not about credit, but accuracy.
Personally, I try to always say what I mean:
GNU when I'm talking about the user tools, usually in contrast to the BSD tools.
Linux when I'm referring specifically to a kernel capability.
Red Hat Linux when I discuss the distribution I use, and the features thereof.
GNU/Linux when I'm talking about GNU/Linux systems in general.
Linux by itself does not fulfill the requirements of a UNIX operating system. GNU/Linux does.
When you understand the term GNU/Linux as the full name of a UNIX platform, rather than an ego-stroking byline, you can see that suggestions like "Apache/Slashdot" aren't valid criticisms.
Removing copyright technology of a work whose copyright has expired, therefore, would not violate the DMCA.
Good point, but how do you suppose that's going to be done? The DMCA outlaws any tools whose primary purpose is to circumvent copyright technology. You're going to find it hard to argue that a tool which can be used to circumvent copyright tech is only going to be used on works which have passed into the public domain, I'll wager.
you cannot force an author to publish a work in a a medium which is easy to copy.
I see where you're coming from, but isn't that the point of copyright? It's a legal grant of the *right* to copy a work which expires, and after which all are supposed to have the right to copy the work. If that right to copy is denied to the public forever, why do the publishers continue to get legal copying monopoly?
Being NAL as I am, I would like to see some discussion of how limited term copyright is expected to work in a future where copyright is enforced by perpetual technological means.
As more information is published on digital media, DRM is becoming a means of enforcing the copyright on the information. However, I know of no DRM systems which provide for expriation of protection. So, while the legal protection may go away after the granted term, the data is still protected technologically. I wonder, what are the legal implications of this?
Copyright was granted on the grounds that after the granted term, the information was to enter the public domain. If the information is designed by the distributors to never enter the public domain, does it still deserve copyright protection? It seems like this is analogous to patents vs. trade secrets where trade secrets have no legal protection because there is no obligation to disclose the way they work. You have to trade one for the other.
While many readers poo-poo the study because it was funded by Clorox, I wonder who else they expect to conduct such studies? Clorox makes cleaning products... it makes sense for them to find out what things need cleaning, no?
I wouldn't expect the average person to go around collecting samples from all of the surfaces in their house to grow in dishes and find problematic places.
The results don't surprise me at all. Anyone who's taken a high-school level biology course has probably done exactly that in class and found that commonly handled items have lots of bacteria. I believe door knobs and phones were the worst surfaces tested by my class. (which reminds me of a particular chapter of the hitchhikers guide...)
2) Microsoft must release full API documentation detailing all APIs that non-OS tasks can call.
I wouldn't stop there. Some of the best products are OS add-ins. New filesystems, security products, even drivers depend on the OS API. Why would you want to leave it out?
one ships in binary
:( I think I'm going to bring this up on the redhat-list and see if anyone has anything to say about this...
I was about to suggest that you include a copy of libstdc++ with your application, but I just noticed that the RPM package and serveral files in the CVS repository all bear the GPL. That would make it illegal to link proprietary applications against libstdc++, wouldn't it?
because you continue to use a proprietary compiler version?
It's not "proprietary". All of the code is available. It's Free Software.
Wow, I was wondering if the Linux media player still existed anywhere... I figured MS would have later hunted down and eliminated all evidence of its existance.
Comments like this make me wish there weren't a 5 point cap on moderation, or a moderation category like "Not repeated enough" (as opposed to redundant :-)
Sale or disposure of the copy does not, however, free the copy from the original copyright. What part of the GPL do you think prohibits the resale of copies of software? The GPL specifically grants all recipients of copies the same rights as the source from which they got the copies.
Does anyone else have a Linux version of *their* media player? Does Real or M$?
:)
Yes, and yes. Real player for Linux is available, and at one point in time, there was even a Media Player for Linux available from MS. The MS player is, as far as I know, gone now though
But on the other disregards *backward* compatibility for dynamic libraries etc
Backward compatibility is provided by compat-libstdc++.
my customers would accept a binary that works over my source compatibility every time. Why? They buy solutions not code.
Smart customers buy solutions that include code. Software that doesn't include code will eventually have to be thrown out, every time.
Another way to say it is that your customers don't buy solutions, they license them. We buy Red Hat Linux.
Red Hat does not pre-announce release dates or version numbers. I find it highly unlikely that 8.0 will follow in anything less than the ~6 month release cycle that they've always followed. IF 8.0 is what follows at all...
We've been told that Hampton was a code name used for an internal development tree, and is not expected to be the name of the final release (whatever the version number)
Red Hat Linux users can get apt from freshrpms.net, and use that, as well.
I've been using apt to update my systems for a while now, and it *rocks*.
What a day to be without moderator points...
...because RPM can't do something like "a.rpm needs library X, let's see if any of the other RPM's in this directory have library X in them."
You should *never* use --nodeps to install packages. The only time that is reasonable is if you've built a particular dependency from source, yourself (which you should avoid).
Certainly, you should never advise new users, in a public forum, that --nodeps is the correct way to go. They *will* end up with non-functioning installations.
That's total bull shit. rpm absolutely, positively does resolve dependencies against both the packages already installed in the system and the packages given to install.
New users should not follow these directions. Other replies to the parent post give proper installation instructions. Moderators should lay down the crack pipe, and decrease the score on the parent post.
Those numbers are only misleading if you don't know how to read them. Top and ps have a reputation for misleading people stemming from users' confusion over what the different segments mean.
To clarify (I hope):
The SIZE of an application reflects the paging area that has been allocated to the application. This includes all of the text and data for the application, all of the mmap'd files, everything.
The SHAREd pages include all pages of the application's memory marked shared. This is independent of whether or not anything is actually sharing the pages. A program may be linked against Motif, for instance; it will show the size of Motif as shared space, although the memory may still be attributed entirely to that process.
The RSS reflects the RAM resident pages for the application's text and data segments. The difference between RSS and SHARED *at least* may be attributed entirly to the program. It's hard to tell if the difference between RSS and SIZE can, as well, since it could be swapped out shared pages.
As an unusual case, X also mmap's the video memory on your graphics card, which inflates its SIZE value.
I'd still say that KDE is *fucking huge*. Given the numbers from the poster, I wonder how much swap is being used. All of the processes listed have much larger paging areas (SIZE) than resident memory area (RSS), which probably means there's a lot of it out in swap. I wonder if these binaries were compiled with debugging symbols and not stripped, or something...
I hate to see the parent marked up at 5. Personally, I think it is far more misleading than the output of 'top'.
Tooltips are very nearly junk. They're only really useful when used to describe icons that don't have labels; that's only acceptable if the labels would have taken up too much space to make the UI usable.
Displaying the description in the app menu should make it immediately obvious what the menu items *do*, and damn what they *are*. Why should anyone care about the name of the application they're using? Isn't the function of the software what's important?
I know about the tooltips, but that doesn't help novices much. Can you imagine a novice user looking at the menu for the first (or second, or ...) time and mouse-over'ing every item? (Ooo, what's this? Ooo, what's this? etc.)
KDE's panel can now display the comment *as the menu label* which is what I suggested to the GNOME devel group way-back-when.
I tried the CVS release of KDE 3 included in Red Hat's Skipjack beta. Like a man admiring his neighbor's well groomed lawn, I've got to say that it looks *beautiful*. There's some good stuff in there.
One of my favorite features is that the panel can optionally display the "description" of each item, rather than the "name" of the application. That's far more useful for the novice user. I suggested that the GNOME panel do that about.... 2 years ago (??) on one of the gnome mailing lists, but never got around to submitting a patch myself.
I don't know for certain, but the fact that I program in a dozen languages probably explains my polyamory.
Ogg Vorbis isn't a standard by any means
Ogg Vorbis has a specification for its file format that doesn't break any previously specified standard. Therefore, Ogg Vorbis can be called a standard.
yEnc, on the other hand, breaks the NNTP standards, and will likely break the MIME standard. That's the difference. yEnc must fit within the standards already specified for the transmition methods it uses, and does not.
Everyone knows that the Tunguska explosion was a result of Nikola Tesla's experiments:
http://www.frank.germano.com/tunguska.htm