And by saying that, I don't mean to imply that I think the P3 is a good choice, (I like the Athlons:-) I just mean that if the P4 is performing like crap for your applications, then you shouldn't use that processor.
it appears to be the floating point unit stalling for data.
Well, if it's stalling for data, your problem is probably that the P4 has a *tiny* L1 data cache compared to... uh... anything. It's only 8K, compared to the Athlons 64K. See the following URLs: http://www.tomshardware.com/cpu/02q2/020402 /p4_240 0-01.html http://www.geek.com/procspec/intel/nort hwood.htm http://www.geek.com/procspec/amd/k7sele ct.htm
It's probably also worth noting that Intel does NOT list the P4 as a "server processor". The P4 is listed as a desktop or workstation processor. Only P3, Xeon, and Itanium chips are recommended for server use: http://www.intel.com/products/browse/process or.htm ?iid=Homepage+Find_Products_Processors&
You might want to show that to management and reconsider your purchase of P4 equipment. Even a P3 is likely to perform better.
The problem isn't that the data can't be read by standard interfaces, but that tar and cpio just don't know about them yet. ACL's, for example, are a critical feature, long missing from open source UNIX platorms (they're common on some other UNIX platorms, and of course NT).
Tar and cpio back up the standard UNIX permission set, but that set is really inadequate. Until they can back up the full set of ACL's, they're basically useless on systems that use them.
The fact that reiserfs doesn't include a "dump" of its own isn't a failing in "dump", but a failure of the ReiserFS developers.
Yes, dump is and always was fs-specific. That's something that's always been understood.
It's also the only way to back up ACL's and other extended metadata. Data backup is good, but file metadata is important, too. You wouldn't back up your data with no file names, would you? File names are a small part of the metadata associated with a file. Tar and cpio only get a subset of that data.
As filesystems move toward extending the amount of metadata they store (ACL's, and extended attributes now, ReiserFS is moving toward ever more complex metadata), backup programs are going to have to be extended to store that information in the archives. Until they do, only dump is reliable.
As implied by the subject, I do like PPC hardware, but I'd chose to run Linux on it.
Those that have switched are quick to point out all of the same beautiful aspects of OS X, and before they do I'll say this: I've seen them. I've used it. I know. You don't have to sell me on OS X. I used it for long enough to know about all of the goodies, and I'll still take Linux and GNOME.
OS X, in trade for "just working", does not fit to the user, expecting the user to fit to the software instead.
Keybindings don't "just work"; I never found documentation listing the standard keys (though I'm sure someone will post a URL in reply to this comment;-) and I can't create new ones to simplify things that I do frequently.
The Terminal doesn't "just work". Actually, the terminal emulator is probably the worst that I've ever used, on any platform.
UNIX source code often doesn't "just work" because OS X's kernel differs from UNIX in ways that are nothing short of bugs, which the developers don't seem keen to fix. (For example, when you try to create an IPv6 socket in 10.1, the kernel returns EPROTONOSUPPORT instead of EAFNOSUPPORT, which it should)
For the same reason I like Emacs, I like Linux and GNOME (especially sawfish): I can make a macro or shortcut of anything. I fit the software to me because I know best how I work. In the end, OS X feels like a pair of too-tight store bought jeans. Linux is more like a tailored pair of pants.
Yes, it is totally browser related. The post that you refer to says that MS doesn't plan on fixing it, but not that it isn't their problem. The problem lies in their PKI implimentation, and regardless of their public face's claims of focus on security and trustworthy computing, they're continuing their old habits of not fixing problems until their customers force them to.
Well, despite the opinions of some, I also hope that dump gets the love it needs from kernel developers soon. There's more to some filesystems than tar or cpio take into account. ACL's spring to mind... Neither tar nor cpio back those up. Basically any file system which offers extended management features will need its own dump program. It's all covered in O'Reiley's "UNIX Backup and Recovery", which everyone who thinks that tar and cpio are always good enough should read.
I think he meant when the main server is slashdotted before the mirrors do their mirror thing. In that case, they probably can't, and the only site with the content is the main one.
Re:I don't think so...
on
Social Robot?
·
· Score: 2
Sure, but some of us do what we can to do otherwise. My mom uses Linux on her computer, as does my girlfriend. As of this weekend, so will my/other/ girlfriend. I'm installing Yellow Dog Linux on her Mac G4:)
Don't be an elitist asshole. If you don't understand what the problem really is, don't comment on it.
This problem has nothing to do with rpm. The problem that Red Hat advertises WRT Ximian is that an upgrade may not upgrade all of the GNOME packages, since Ximian's may be newer (and this is the correct behavior, according to any packager). However, because some packages may be updated, and others may not, you don't have a tested, known-stable GNOME platform. dpkg and apt don't do anything special that prevents that from happening.
So, what do we know about who is affected? Immediately after reading the announcement, I checked Red Hat Linux's build of OpenSSH. The configure script positively reports that the affected authentication mechanisms are not available. 'ssh -v' does not indicate that challenge-response authentication methods are available either. I imagine that other Linux distros are similar?
RHL configure output: OpenSSH has been configured with the following options: ...
Smartcard support: no
S/KEY support: no
BSD Auth support: no
...all C++ related shared libraries...must be recompiled before you can link with them.
Yeah, no shit. GCC 3.x doesn't produce C++ binaries compatible with those built by previous GCC's. That's not news, that's the way it's always been. One of the benefits of gcc 3.x is that they've promised a stable C++ ABI.
The fact that you have to rebuild the C++ libraries to build C++ applications doesn't mean that GCC isn't production-ready. It means that the base system wasn't build with GCC 3.x and nothing more.
go read usenet comp.os.linux.* you'll find its called pam
pam doesn't change settings, that's rediculous. pam is just an authentication library.
gcc 3.x is currently blacklisted by everyone its just too full of bugs for a production enviroment
Sounds to me like you're just repeating what you've heard, with no understanding of the subject. 3.0 wasn't a very good release, it had problems in several specific areas. 3.1 has been spoken on quite favorably, on the other hand. It seems to be an excellent release, and will be the base compiler of United Linux, and quite likely Red Hat's next Linux distro.
It wouldn't have been compatible with the rest of the series, and hasn't been out long enough to be tested well. That's the biggest part of your misperception of "just too early". For major system components, "just to early" is *way* too early.
- mozilla (not v1)
So it doesn't have the 1.0 stamp on it... Can you name any major flaws in the release? Would it have been worth delaying the WHOLE distro to wait for those? Mozilla had a well known release timeline; if Red Hat thought that 1.0 was worth the wait, they knew when it was coming.
- kde 3.0.0 (effectively a late beta)
Way off. KDE 3.0.0 in Red Hat Linux 7.3 is a CVS snapshot from just before 3.0.1. On the other side of release from beta, this release is considerably more stable than the KDE team's 3.0.0 packages.
Well, it looks like this version finally includes LPRng.
I've been convinced that no one in slackware gives a damn about security since 8.0 included lpr-0.48, a remotely root exploitable BSD based lpr that was fixed YEARS before 8.0 was released. Hello? Someone is asleep at the wheel.
At the same time, I thought it was quite funny. The slackware users that I work with were complaining about Red Hat when I was hired because "it ships with a remotely exploitable lpr running by default". At that time, that hadn't been true for over two years.
Re:Binary Distros Are Dead
on
Is RPM Doomed?
·
· Score: 2
NP. So was I when I first read the article.;-)
Re:Binary Distros Are Dead
on
Is RPM Doomed?
·
· Score: 2
Yes, you can get the diffs or update from CVS, but only if you're updating by hand. However, that doesn't save any time, just bandwidth. Updates by hand are going to be a HELL of a lot slower even than downloading all of the full source tarballs and building them automatically. Don't forget that with manual updates, you're also responsible for backing up your config files and restoring them after the update. Automated systems all (that I know of) take care of config files automatically.
Re:Install redhat in 2 minutes.. hahaha
on
Is RPM Doomed?
·
· Score: 2
I'm sorry. You're right. I wrote that right after I woke up. It takes all of two minutes to transfer the files over HTTP and unpack them.
The whole process takes just under five minutes. My own interaction is only needed for 20 seconds, however; I have to pull the floppy after the machine stops reading it.
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
I didn't say you couldn't. You only asked why you'd want to split one source into multiple binary packages.
All the same, try it sometime with a non-trivial package. It's not as simple as it seems at first, especially if you want the source packages builds without those optional packages' dependencies.
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
Maybe your package is a library, and you want to split it into "library" and "library-devel" packages, so that users don't need extra headers and devel libraries sitting around, filling up their disks.
Or, maybe you have a single source which builds a modular application, and some of those modules have dependencies that the package as a whole doesn't need. The Courier-MTA builds separate courier-ldap, courier-mysql, courier-pgsql packages so that users who want virtual hosting/aliasing using those backends can install the appropriate package, but those who don't use those features don't need openldap, mysql, and postgresql installed to run Courier.
everything you know is wrong.
on
Is RPM Doomed?
·
· Score: 2
Wow... This is one of the most factually flawed and misinformed articles I've read in a long damn time. And right after I woke up... I've got to find better ways to start my day.
Some of my bigger complaints:
...The installation fails, reporting a missing dependent package without which it will not install or function correctly.
LISTEN to what it's telling you. This is always the first complaint about rpm from those who don't like it. However, getting rid of dependency information DOESN'T GET RID OF DEPENDENCIES. Without the information before install, and without those checks, the software won't function after its installed. That information is absolutely critical when software has to continue functioning.
Upgrading an RPM-based distribution is risky at best
Based on what? Have you ever had a major failure? The only problems I'm aware of stem from replacing vendor packages with third party packages, which may not match the layout of the originals (or the new vendor packages.)
it has created enormous fragmentation between distributions
Nothing has created fragmentation but their own opinions about where things belong. Source distribution doesn't solve that.
developers are forced to take this fragmentation into account when creating binary packages
No we don't. Autoconf/automake follow the FHS for installation, and that's what most of us use.
with Debian, you only ever install once; upgrades are not only fully supported, but strongly encouraged.
That's not a result of dpkg, it's a result of apt. Apt is some bad-ass software, and I rejoice that it's now available for rpm. I've used it to upgrade a number of Red Hat Linux 7.2 systems to 7.3, and even upgraded one RHL 6.0 system to 7.3.
Not long ago, an RPM would work, period. The only possible concern was whether it was built against libc5 or glibc. -- Dennis Powell
Not long ago, GNU/Linux systems didn't provide many *useful* libraries for programmers to work with. libc as the basic dependency meant that developers had to impliment their own basic needs over and over again, which is one of the reasons that UNIX has not been a popular development platform in many areas.
Many of you will have remembered that the RPM Package Manager went from 3.x to 4.x without backward compatibility
Um... no. rpm went from v3 to v4 and it was backward compatible. rpm v4 could install all of rpm v3's packages. rpm 3.0.5 was also introduced, which could handle rpm v4 binary packages.
I just don't see how the distributions are going to bend over to offer concessions to each other.
Um... are you TOTALLY ignoring United Linux and the LSB? Both of these are multi-vendor efforts to standardize the basic system on which GNU/Linux distributions are built.
My own conclusion: If you have problems with dependencies, then the package was not built for your platform. There is, however, a meeting point between source installs and the benefits of rpm: The source rpm. If your binary rpm was built for some other platform, get the.src.rpm instead and build that. It's easy: rpm --rebuild package-version.src.rpm
Slashdot Mirror
Even a P3 is likely to perform better.
:-) I just mean that if the P4 is performing like crap for your applications, then you shouldn't use that processor.
And by saying that, I don't mean to imply that I think the P3 is a good choice, (I like the Athlons
it appears to be the floating point unit stalling for data.
2 /p4_240 0-01.htmlt hwood.htme ct.htm
s or.htm ?iid=Homepage+Find_Products_Processors&
Well, if it's stalling for data, your problem is probably that the P4 has a *tiny* L1 data cache compared to... uh... anything. It's only 8K, compared to the Athlons 64K. See the following URLs:
http://www.tomshardware.com/cpu/02q2/02040
http://www.geek.com/procspec/intel/nor
http://www.geek.com/procspec/amd/k7sel
It's probably also worth noting that Intel does NOT list the P4 as a "server processor". The P4 is listed as a desktop or workstation processor. Only P3, Xeon, and Itanium chips are recommended for server use:
http://www.intel.com/products/browse/proces
You might want to show that to management and reconsider your purchase of P4 equipment. Even a P3 is likely to perform better.
The problem isn't that the data can't be read by standard interfaces, but that tar and cpio just don't know about them yet. ACL's, for example, are a critical feature, long missing from open source UNIX platorms (they're common on some other UNIX platorms, and of course NT).
Tar and cpio back up the standard UNIX permission set, but that set is really inadequate. Until they can back up the full set of ACL's, they're basically useless on systems that use them.
Dump doesn't work with reiserFS
The fact that reiserfs doesn't include a "dump" of its own isn't a failing in "dump", but a failure of the ReiserFS developers.
Yes, dump is and always was fs-specific. That's something that's always been understood.
It's also the only way to back up ACL's and other extended metadata. Data backup is good, but file metadata is important, too. You wouldn't back up your data with no file names, would you? File names are a small part of the metadata associated with a file. Tar and cpio only get a subset of that data.
As filesystems move toward extending the amount of metadata they store (ACL's, and extended attributes now, ReiserFS is moving toward ever more complex metadata), backup programs are going to have to be extended to store that information in the archives. Until they do, only dump is reliable.
Spread the word.
As implied by the subject, I do like PPC hardware, but I'd chose to run Linux on it.
;-) and I can't create new ones to simplify things that I do frequently.
Those that have switched are quick to point out all of the same beautiful aspects of OS X, and before they do I'll say this: I've seen them. I've used it. I know. You don't have to sell me on OS X. I used it for long enough to know about all of the goodies, and I'll still take Linux and GNOME.
OS X, in trade for "just working", does not fit to the user, expecting the user to fit to the software instead.
Keybindings don't "just work"; I never found documentation listing the standard keys (though I'm sure someone will post a URL in reply to this comment
The Terminal doesn't "just work". Actually, the terminal emulator is probably the worst that I've ever used, on any platform.
UNIX source code often doesn't "just work" because OS X's kernel differs from UNIX in ways that are nothing short of bugs, which the developers don't seem keen to fix. (For example, when you try to create an IPv6 socket in 10.1, the kernel returns EPROTONOSUPPORT instead of EAFNOSUPPORT, which it should)
For the same reason I like Emacs, I like Linux and GNOME (especially sawfish): I can make a macro or shortcut of anything. I fit the software to me because I know best how I work. In the end, OS X feels like a pair of too-tight store bought jeans. Linux is more like a tailored pair of pants.
I would mod this up, but I can't both do so and praise the poster for the pure poetry of their comment. :)
"What would you prefer, gold spandex?"
IIRC, the question was whether he'd prefer blue and gold spandex, which ALL Of the X-Men originally wore.
Yes, it is totally browser related. The post that you refer to says that MS doesn't plan on fixing it, but not that it isn't their problem. The problem lies in their PKI implimentation, and regardless of their public face's claims of focus on security and trustworthy computing, they're continuing their old habits of not fixing problems until their customers force them to.
Well, despite the opinions of some, I also hope that dump gets the love it needs from kernel developers soon. There's more to some filesystems than tar or cpio take into account. ACL's spring to mind... Neither tar nor cpio back those up. Basically any file system which offers extended management features will need its own dump program. It's all covered in O'Reiley's "UNIX Backup and Recovery", which everyone who thinks that tar and cpio are always good enough should read.
I think he meant when the main server is slashdotted before the mirrors do their mirror thing. In that case, they probably can't, and the only site with the content is the main one.
Sure, but some of us do what we can to do otherwise. My mom uses Linux on her computer, as does my girlfriend. As of this weekend, so will my /other/ girlfriend. I'm installing Yellow Dog Linux on her Mac G4 :)
Yeah, but the difference of the area of two circles in relative terms is (r2 - r1)^2, not (r2 - r1)^2 * pi.
I think I need a new sig:
Don't be an elitist asshole. You're just going to look like an idiot.
dpkg never had this problem.
Don't be an elitist asshole. If you don't understand what the problem really is, don't comment on it.
This problem has nothing to do with rpm. The problem that Red Hat advertises WRT Ximian is that an upgrade may not upgrade all of the GNOME packages, since Ximian's may be newer (and this is the correct behavior, according to any packager). However, because some packages may be updated, and others may not, you don't have a tested, known-stable GNOME platform. dpkg and apt don't do anything special that prevents that from happening.
CmdrTaco: Watch Lilo & Stich instead ;)
I had to look that up in my universal tranlator, because it sounded a bit odd. Apparently it translates to english as:
I am Disney's little bitch. Fund the war on freedom.
Paying the people who oppress you is dumb with a capital "DUMB", Taco.
So, what do we know about who is affected? Immediately after reading the announcement, I checked Red Hat Linux's build of OpenSSH. The configure script positively reports that the affected authentication mechanisms are not available. 'ssh -v' does not indicate that challenge-response authentication methods are available either. I imagine that other Linux distros are similar?
RHL configure output:
OpenSSH has been configured with the following options:
...
Smartcard support: no
S/KEY support: no
BSD Auth support: no
...all C++ related shared libraries...must be recompiled before you can link with them.
Yeah, no shit. GCC 3.x doesn't produce C++ binaries compatible with those built by previous GCC's. That's not news, that's the way it's always been. One of the benefits of gcc 3.x is that they've promised a stable C++ ABI.
The fact that you have to rebuild the C++ libraries to build C++ applications doesn't mean that GCC isn't production-ready. It means that the base system wasn't build with GCC 3.x and nothing more.
go read usenet comp.os.linux.* you'll find its called pam
pam doesn't change settings, that's rediculous. pam is just an authentication library.
gcc 3.x is currently blacklisted by everyone its just too full of bugs for a production enviroment
Sounds to me like you're just repeating what you've heard, with no understanding of the subject. 3.0 wasn't a very good release, it had problems in several specific areas. 3.1 has been spoken on quite favorably, on the other hand. It seems to be an excellent release, and will be the base compiler of United Linux, and quite likely Red Hat's next Linux distro.
- gcc (where is v3.1)?
It wouldn't have been compatible with the rest of the series, and hasn't been out long enough to be tested well. That's the biggest part of your misperception of "just too early". For major system components, "just to early" is *way* too early.
- mozilla (not v1)
So it doesn't have the 1.0 stamp on it... Can you name any major flaws in the release? Would it have been worth delaying the WHOLE distro to wait for those? Mozilla had a well known release timeline; if Red Hat thought that 1.0 was worth the wait, they knew when it was coming.
- kde 3.0.0 (effectively a late beta)
Way off. KDE 3.0.0 in Red Hat Linux 7.3 is a CVS snapshot from just before 3.0.1. On the other side of release from beta, this release is considerably more stable than the KDE team's 3.0.0 packages.
Well, it looks like this version finally includes LPRng.
I've been convinced that no one in slackware gives a damn about security since 8.0 included lpr-0.48, a remotely root exploitable BSD based lpr that was fixed YEARS before 8.0 was released. Hello? Someone is asleep at the wheel.
At the same time, I thought it was quite funny. The slackware users that I work with were complaining about Red Hat when I was hired because "it ships with a remotely exploitable lpr running by default". At that time, that hadn't been true for over two years.
NP. So was I when I first read the article. ;-)
Yes, you can get the diffs or update from CVS, but only if you're updating by hand. However, that doesn't save any time, just bandwidth. Updates by hand are going to be a HELL of a lot slower even than downloading all of the full source tarballs and building them automatically. Don't forget that with manual updates, you're also responsible for backing up your config files and restoring them after the update. Automated systems all (that I know of) take care of config files automatically.
I'm sorry. You're right. I wrote that right after I woke up. It takes all of two minutes to transfer the files over HTTP and unpack them.
The whole process takes just under five minutes. My own interaction is only needed for 20 seconds, however; I have to pull the floppy after the machine stops reading it.
I didn't say you couldn't. You only asked why you'd want to split one source into multiple binary packages.
All the same, try it sometime with a non-trivial package. It's not as simple as it seems at first, especially if you want the source packages builds without those optional packages' dependencies.
Maybe your package is a library, and you want to split it into "library" and "library-devel" packages, so that users don't need extra headers and devel libraries sitting around, filling up their disks.
Or, maybe you have a single source which builds a modular application, and some of those modules have dependencies that the package as a whole doesn't need. The Courier-MTA builds separate courier-ldap, courier-mysql, courier-pgsql packages so that users who want virtual hosting/aliasing using those backends can install the appropriate package, but those who don't use those features don't need openldap, mysql, and postgresql installed to run Courier.
Wow... This is one of the most factually flawed and misinformed articles I've read in a long damn time. And right after I woke up... I've got to find better ways to start my day.
...The installation fails, reporting a missing dependent package without which it will not install or function correctly.
.src.rpm instead and build that. It's easy:
Some of my bigger complaints:
LISTEN to what it's telling you. This is always the first complaint about rpm from those who don't like it. However, getting rid of dependency information DOESN'T GET RID OF DEPENDENCIES. Without the information before install, and without those checks, the software won't function after its installed. That information is absolutely critical when software has to continue functioning.
Upgrading an RPM-based distribution is risky at best
Based on what? Have you ever had a major failure? The only problems I'm aware of stem from replacing vendor packages with third party packages, which may not match the layout of the originals (or the new vendor packages.)
it has created enormous fragmentation between distributions
Nothing has created fragmentation but their own opinions about where things belong. Source distribution doesn't solve that.
developers are forced to take this fragmentation into account when creating binary packages
No we don't. Autoconf/automake follow the FHS for installation, and that's what most of us use.
with Debian, you only ever install once; upgrades are not only fully supported, but strongly encouraged.
That's not a result of dpkg, it's a result of apt. Apt is some bad-ass software, and I rejoice that it's now available for rpm. I've used it to upgrade a number of Red Hat Linux 7.2 systems to 7.3, and even upgraded one RHL 6.0 system to 7.3.
Not long ago, an RPM would work, period. The only possible concern was whether it was built against libc5 or glibc. -- Dennis Powell
Not long ago, GNU/Linux systems didn't provide many *useful* libraries for programmers to work with. libc as the basic dependency meant that developers had to impliment their own basic needs over and over again, which is one of the reasons that UNIX has not been a popular development platform in many areas.
Many of you will have remembered that the RPM Package Manager went from 3.x to 4.x without backward compatibility
Um... no. rpm went from v3 to v4 and it was backward compatible. rpm v4 could install all of rpm v3's packages. rpm 3.0.5 was also introduced, which could handle rpm v4 binary packages.
I just don't see how the distributions are going to bend over to offer concessions to each other.
Um... are you TOTALLY ignoring United Linux and the LSB? Both of these are multi-vendor efforts to standardize the basic system on which GNU/Linux distributions are built.
My own conclusion: If you have problems with dependencies, then the package was not built for your platform. There is, however, a meeting point between source installs and the benefits of rpm: The source rpm. If your binary rpm was built for some other platform, get the
rpm --rebuild package-version.src.rpm